Scope minimal Code Bridge vertical slice

[shiny-code-bot]

Objective

Scope a minimal Code Bridge/browser/control vertical slice after app-server/Desktop compatibility is validated.

Finish Line

Code Bridge MVP scope is narrowed to a local event/screenshot/control vertical slice after compatibility validation.

Current Status

Updated 2026-06-16 by Code.

State: Completed minimal Code Bridge vertical slice. The standalone local bridge path now has protocol, trust/payload bounds, service/client coverage, browser-shaped fixture coverage, loopback browser CORS support, and an opt-in real-browser witness.

Completed evidence:

• Define Code Bridge protocol, trust, and payload contract #45, Build minimal Code Bridge service skeleton #46, Add Code Bridge app client and subscriber vertical slice #47, and Align discord-blue Every Code bridge with shared protocol #48 are complete.
• PR Add Code Bridge browser fixture witness #107 added the browser-shaped protocol fixture for event, screenshot, and control round trips.
• PR Add loopback CORS support for Code Bridge #108 added loopback browser CORS/preflight support for the bridge HTTP/SSE surfaces.
• PR Add Code Bridge live browser witness #109 added the live browser witness: a real browser page connects to the local bridge, publishes pageview/console events, responds with a deterministic nonblank canvas screenshot, and handles a whitelisted JavaScript control request.

Validation evidence:

• cargo test --manifest-path codex-rs/Cargo.toml -p codex-code-bridge-client --no-fail-fast
• cargo test --manifest-path codex-rs/Cargo.toml -p codex-code-bridge-client --test live_browser_witness -- --ignored --nocapture, with the printed local URL opened in a real browser.
• PR Add Code Bridge live browser witness #109 passed PR CI, including the macOS app build.

Scope split:
#49 and #50 remain open as follow-up integration plans for Launchplane provenance and a deliberately thin app-server gate. They are no longer treated as unfinished acceptance criteria for this minimal standalone bridge slice.

Agent-backed decisions remain current:

• Do not embed the full bridge telemetry/control plane in app-server first. App-server can integrate later, but should not host high-volume screenshots/logs/control traffic by default.
• Keep two related bridge families distinct: the planned Code Bridge app telemetry/control surface, and discord-blue's existing Every Code remote session/approval/thread bridge. Align them deliberately; do not collapse them accidentally.
• Launchplane remains orchestration/work-request authority. Bridge metadata can correlate events to Launchplane work, but Code Bridge must not become a second planning backend.
• Security/trust/payload bounds are first-slice requirements, not polish: no trust-localhost fallback, no unbounded logs/screenshots, no raw product-specific state in the core protocol.

Scope

In:

• Local bridge event stream for console/error/pageview.
• Screenshot request path.
• One bounded JavaScript/control command path.
• Local metadata/secret handling and capability gating.

Out:

• No broad browser automation platform.
• No remote bridge/control surface.
• No Code Bridge implementation before app-server/Desktop compatibility gaps are understood.

Acceptance Criteria

• Minimal bridge protocol has bounded payloads and local-only trust assumptions.
• Screenshot and JavaScript/control commands are capability-gated.
• Browser/UI validation proves nonblank screenshot and event/control round trip.
• Security/privacy boundaries are documented before any remote extension.

Relationships

Child of #28. Depends on app-server/Desktop compatibility validation. Related to restored cbusillo/code Code Bridge evidence to be classified in the ledger.

Validation

Use browser tools and/or bridge telemetry to validate the first vertical slice when implemented.

Decisions

Code Bridge is MVP-adjacent and should be additive after compatibility gates, not a substrate mutation.

Open Questions

Resolved direction after agent review: do not start by embedding the full Code Bridge control plane in app-server. Start with a standalone Code Bridge service/daemon and shared protocol.

Architecture question for implementation: define the smallest shared bridge protocol and service boundary that can support trusted local clients, bounded events, screenshots, and capability-gated control, while leaving product adapters outside the core. App-server may later consume that service through MCP/tools or a thin v2 bridge surface, but should not become the high-volume telemetry host or product-adapter registry by default.

Product boundaries:

• discord-blue already runs an Every Code bridge listener inside the Discord Blue service; migrate that toward the shared protocol.
• Launchplane should remain work orchestration/runtime state first; add a bridge adapter only when a Launchplane-run product needs live app observation/control.
• App-server should keep Desktop/session compatibility stable and avoid product-specific bridge logic.