Investigate Codex desktop app remote control compatibility

[shiny-code-bot]

Current Status

State: Completed technical feasibility scan; recommendation is no-go for native Codex desktop remote-control compatibility right now.
Next action: Keep #226/#227 parked until Every Code chooses an app-server client direction. Revisit this only if we decide to build an Every Code remote relay or a deliberately local desktop bridge.
Blocked by: None.
Waiting for: Product decision on whether desktop remote control should replace or augment the existing remote inbox / Discord UI workflow.
Last verified: 2026-05-30 against openai/main at 8acaec73b6 and Every Code origin/main at cf36139313.

Findings:

• Codex desktop remote control is not a raw local app-server websocket. Current upstream runs through app-server daemon / foreground codex remote-control, backend enrollment under /wham/remote/control/server/enroll, a backend websocket under /wham/remote/control/server, ChatGPT account auth, installation identity, persisted environment/server IDs, and current server-token refresh support.
• The wire protocol multiplexes virtual remote clients with client IDs, stream IDs, server/client envelopes, ACK cursors, chunk segmentation, reconnect/backoff, status notifications, and idle client cleanup.
• Every Code currently has two different surfaces: hardened local app-server stdio/ws JSON-RPC (code app-server --listen, loopback-only ws and browser Origin rejection from Harden Every Code app-server websocket transport #225) and TUI remote inbox (remote_inbox) for replies, continue/pause, new/end session, approval decisions, user-input answers, and status mirroring.
• Those Every Code surfaces do not implement Codex remote-control enrollment, daemon lifecycle, remote-control status notifications, server-token auth, virtual client tracking, or the upstream app-server transport crate.
• Direct desktop compatibility would therefore require either adopting the upstream app-server daemon/transport/auth stack and aligning product identity with OpenAI backend assumptions, or building a separate bridge that translates Codex app-server JSON-RPC/remote-control expectations into Every Code's local app-server / remote-inbox behavior.

Recommendation:

• Do not port upstream remote-control wholesale for desktop compatibility now. It is product/backend/auth infrastructure, not a small protocol parity patch.
• Preserve the hardened local app-server boundary from Harden Every Code app-server websocket transport #225 and keep the existing remote inbox / Discord UI workflow as the practical remote-control path for Every Code.
• If this becomes a product priority, start with a design spike for an Every Code-owned relay or a local-only desktop bridge with explicit auth, threat model, and protocol translation scope. Do not treat Codex desktop compatibility as an upstream import task.

Finish Line

We know whether the Codex desktop app can control Every Code sessions, what protocol/auth/identity changes are required, and whether this should replace part of the Discord UI workflow.

Acceptance Criteria

• Identify the Codex desktop app remote-control protocol, transport endpoints, auth requirements, and session discovery mechanism.
• Compare those assumptions against Every Code's app-server and local runtime surfaces.
• Determine the smallest compatibility path: protocol shim, app-server parity port, config flag, separate bridge, or reject.
• Evaluate product value versus Discord UI reliance, including security and user trust boundaries.
• Produce a go/no-go recommendation with implementation scope.

Notes

This is separate from upstream-port intake. Success is not “make desktop work at any cost”; success is knowing whether desktop remote control would materially improve Every Code's product loop.

Relationships

• related: Harden Every Code app-server websocket transport #225 - Harden Every Code app-server websocket transport #225
• related: Add initial turns page to app-server thread resume #226 - Add initial turns page to app-server thread resume #226
• related: Define app-server remote history redaction policy #227 - Define app-server remote history redaction policy #227

[shiny-code-bot]

Completed the compatibility investigation and recorded the recommendation in Current Status.

Result: no-go for native Codex desktop remote-control compatibility right now.

Why:

• Current upstream Codex remote control is backend-mediated, authenticated, and daemon-oriented. It uses ChatGPT account auth, installation/server/environment identity, backend enrollment and websocket endpoints, server-token refresh, multiplexed virtual clients, ACKs, chunking, reconnect/backoff, and remote-control status notifications.
• Every Code currently has separate surfaces: hardened local app-server JSON-RPC and TUI remote inbox for the remote UI workflow. It does not have the upstream remote-control transport/daemon/enrollment stack.
• A direct Codex desktop path would be product/backend/auth work, not a small app-server parity port.

Recommendation: keep Every Code's current remote inbox / Discord UI path and the hardened local app-server boundary. Revisit only with a product decision to build an Every Code-owned relay or a narrow local-only desktop bridge with explicit auth and protocol translation scope.