P0: functional smoke writes Python bytecode into the signed Workbench app

[100yenadmin]

P0 problem

The Workbench functional-smoke workflow invokes the packaged bridge interpreter directly for the macOS framework import probe:

"$BRIDGE_PYTHON" -I -c ...

That path bypasses the normal evaos-desktop-bridge wrapper. The workflow also runs under env -i, while Python isolated mode (-I) ignores PYTHON* environment variables. As a result, the wrapper's existing PYTHONDONTWRITEBYTECODE=1 and external PYTHONPYCACHEPREFIX protections cannot apply to this probe.

The currently installed v2.1.35 app contains bytecode caches written after its earlier clean installed-app proof. Those added sealed resources make current deep codesign and spctl verification fail even though the stapled notarization ticket remains valid. This installed app is not valid release proof and must not be repaired by deleting files in place.

Root cause

• Unsafe direct launch: .github/workflows/workbench-functional-smoke.yml packaged bridge import probe.
• Existing protected launch path: the generated Contents/Resources/Bridge/evaos-desktop-bridge wrapper sets no-bytecode/external-cache policy before executing bundled Python.
• -I does not disable bytecode generation; Python's CLI -B flag does.

Required fix

• Change the exact packaged import probe to invoke "$BRIDGE_PYTHON" -I -B -c ....
• Strengthen the release-gate parser so a functional-smoke workflow that directly invokes the packaged interpreter without -B is rejected.
• Add a decoy regression proving nearby or unrelated -B text cannot satisfy the exact probe requirement.
• Audit the Workbench workflows/scripts for any other direct bundled-interpreter execution and apply the same invariant without altering normal connector behavior.

Acceptance criteria

• Focused tests prove the exact packaged import probe contains both -I and -B.
• A fresh signed/notarized candidate contains zero __pycache__ directories and zero .pyc files inside the app before smoke.
• Run the real functional-smoke/import path against the installed candidate.
• The installed app still contains zero in-bundle bytecode caches afterward.
• App and mounted-DMG app pass deep strict codesign, stapler, and spctl verification after the smoke.
• The existing external cache/wrapper behavior remains covered.
• No deletion, permission reset, or in-place mutation of the already-damaged installed v2.1.35 app is used as proof.
• No change to CUA-primary / Peekaboo-fallback engine order, broker authority, pairing, stop/revoke, kill switch, or customer runtime.

Release boundary

Source and unit tests alone are not sufficient. This issue blocks a 2.1.36 release-good claim until a fresh signed artifact passes the post-smoke installed-bundle integrity checks above.

[coderabbitai]

🔗 Related PRs

#403 - fix: recover Mac control installed app states [merged]
#449 - Fix legacy app stale owner proof path [merged]
#462 - [codex] Document Workbench release proof lanes [merged]
#636 - fix(evaos): enforce no-ACP release packaging [merged]
#675 - P0: bundle self-contained Mac connector runtime [merged]

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[evaos-code-review-bot]

evaOS issue enrichment

Issue: #694 - P0: functional smoke writes Python bytecode into the signed Workbench app
State: open; milestone: Workbench Runtime Reliability Release Train

Related issues/PRs: none detected from issue metadata.
Existing labels: bug, evaos, public-beta, ready-for-agent, area:native-companion, area:release, risk:security, kind:integration, release-train:runtime-reliability, priority:P0.
Suggested labels: security, tests, support.
Suggested owners: none.

Related context

• No same-repo issue/PR references detected in issue metadata.

Agent-start packet

Problem shape: P0: functional smoke writes Python bytecode into the signed Workbench app - ## P0 problem The Workbench functional-smoke workflow invokes the packaged bridge interpreter directly for the macOS framework import probe: "$BRIDGE_PYTHON" -I -c ... That path bypasses the normal
Product fit: Product/market issue; check vision fit, customer value, and whether external precedent can reduce time-to-market.
Implementation wedge: Start with a bounded adapter/contract or dry-run packet before changing live runtime behavior.

Build / borrow / buy scan:

• Build: identify the smallest implementation wedge that proves the issue without broad rollout.
• Borrow: inspect same-repo prior art, repo memory, GitNexus context, and allowlisted cross-repo examples first.
• Buy/use: run capped external OSS/library/API/current-market research with citations, observed dates, and why each source matters.
• Library choice: compare maintenance, API fit, license, bundle/runtime cost, and integration proof.

Candidate sources:

• VISION.md / repo policy / repo-memory.md / GitNexus packet.
• Same-repo issues and PRs referenced by issue metadata.
• Allowlisted cross-repo GitHub examples with direct issue/PR/repo URLs.
• External OSS repositories or library/API docs with freshness dates.
• Current market/product examples, capped and cited, only when they change implementation direction.

Acceptance criteria:

• Preserve and execute the issue's stated acceptance criteria.
• Include source citations for any external OSS/library/current-market claims.
• Keep issue-enrichment comments sticky and idempotent.
• Keep labels, owners, reviewers, and roadmap fields suggestion-only.

Proof plan:

• Focused unit/fixture test for the changed planner behavior.
• Dry-run issue-enrichment evidence packet before live comment posting.
• Redaction check for issue body, citations, and generated markdown.
• Contract or degraded-mode proof before runtime promotion.
• Dependency/license/API-fit note before adding or relying on a package.

Known traps:

• Do not treat related links as proof by themselves; each source needs a reason why it matters.
• Do not scan old issue backlogs or exceed repo-level enrichment throttles.
• External research must stay capped, cited, fresh-dated, and redacted.
• Technical severity alone can miss product/UX regressions; include product-manager review framing.

Non-goals:

• Do not auto-apply labels, owners, reviewers, roadmap fields, or milestones.
• Do not bulk-enrich old backlog issues from this planner output.
• Do not claim external market or OSS research was performed unless cited sources are present.

Context-source taxonomy:

• [enabled] vision_repo_policy_memory_gitnexus: Use repo vision, policy, memory, and GitNexus first before external research.
• [enabled] same_repo_issues_prs: No explicit same-repo references detected; still safe as bounded local context.
• [enabled] allowlisted_cross_repo_github: Triggered by issue class; keep to configured allowlist and source caps.
• [enabled] external_oss_examples: Use for build/borrow/buy precedent with citations and observed dates.
• [enabled] library_api_docs: Use when implementation may depend on a module, SDK, API, or framework choice.
• [enabled] current_market_examples: Use for product/UX/market positioning issues with freshness dates.
• [enabled] internal_mcp_docs: Use internal docs/MCP context when available; missing context is degraded, not blocking.

Validation suggestions

• Confirm owner, acceptance criteria, and validation evidence before implementation.

Triage gaps

• Owner or reviewer signal not detected in issue body.

No labels, owners, reviewers, or roadmap fields were changed by this bot.