Review experimental remote-control and Codex mobile host boundary

[nisavid]

This was generated by AI during triage.

Summary

Review the experimental Linux remote-control and Codex mobile host boundary before general-ready treatment.

Source

Migrated from docs/maintainers/security-backlog.md.

Maintained Docs

• Product source of truth: PRODUCT.md
• Design source of truth: DESIGN.md
• Security backlog index and review workflow: docs/maintainers/security-backlog.md
• Threat model: docs/maintainers/threat-model.md
• Package and runtime maintenance: docs/maintainers/package-runtime-maintenance.md

Context

The remote-control-ui and remote-mobile-control port integrations expose Linux host plumbing for official app remote-control and Codex mobile surfaces. The Linux path uses software device keys under XDG config instead of the macOS native key module, preserves local app-server remote-control config, and exposes UI surfaces still governed by OpenAI-hosted account, enrollment, MFA, mobile-client authorization, and remote-access policy.

Triage Outcome

Snailflyer's host-state matrix is incorporated into this issue's scope. A connected-looking UI is not enough by itself to prove that the intended live host, app-server or managed daemon, and thread/session are current, reachable, and authorized.

This issue is triaged as enhancement plus ready-for-human: repo-local review, docs, and tests can be agent-led, but closure requires human-assisted live mobile/account evidence for the end-to-end host-state matrix.

Review Gate

Run the @codex-security workflow before treating implementation as review-ready.

Review evidence must include a host-state matrix that verifies:

• The enrollment state shown in UI corresponds to current account/mobile enrollment state, not local UI plausibility alone.
• The intended host's app-server or managed remote-control daemon is alive and reachable.
• The Linux remote-control device key exists in the configured XDG device-key store with owner-only file permissions.
• The mobile side can see the intended host thread/session.
• A first mobile action or message is applied to the intended host thread/session.
• Stale, revoked, unauthorized, or mismatched hosts are rejected instead of displayed as connected.

Desired State

• @codex-security reviews remote-control UI gates, Codex mobile setup copy, app-server config preservation, generated bundle patch descriptors, host-state evidence, and the Linux device-key provider before the feature is treated as general-ready.
• The Linux device-key store remains under ${XDG_CONFIG_HOME:-$HOME/.config}/codex-app/ with owner-only file modes and no key material in logs or patch reports.
• Fork-side UI patches expose Linux host plumbing without fabricating connected-client, MFA, enrollment, access-required, remote-environment, host-liveness, or thread/session state.
• Review evidence distinguishes OpenAI-hosted account/mobile authorization state from local generated-app UI state.
• Review evidence proves the first mobile-side action reaches the intended live host thread/session before this issue is closed.
• Docs keep experimental fork-side enablement distinct from upstream account availability and mobile-client authorization.

[coderabbitai]

🔗 Related PRs

#12 - docs: audit fork divergence docs [merged]
#44 - docs: capture upstream README sync guidance [merged]
#76 - docs(upstream): disambiguate fork upstream terminology [merged]
#86 - Validate webview startup assets [merged]
#90 - fix(port-integrations): harden open-target discovery inputs [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!

[Snailflyer]

One review gate I would add here: separate "fork-side UI state is plausible" from "the intended host/app-server state is real and current".

For remote-control/mobile readiness I would want an end-to-end matrix that records:

• enrollment state shown in UI
• host/app-server process alive
• device key present with owner-only mode
• thread/session visible from the mobile side
• first mobile action or message applied to the intended host thread
• stale/revoked/unauthorized host rejected instead of shown as connected

That last applied to intended host thread check catches a lot of false-green remote-control states.

As a self-hosted comparison point, Faryo deliberately avoids account-side session discovery and keeps tmux as the source of truth. The redacted walkthrough shows browser/phone short input plus text/file handoff landing back in the same live tmux-backed session:
https://github.com/Snailflyer/faryo/releases/download/v1.0.7/faryo-public-redacted-same-session-handoff-walkthrough-20260528-0120.gif

[nisavid]

This was generated by AI during triage.

Thanks for writing this up, @Snailflyer. I think I follow the concern: a connected-looking remote-control UI is not enough by itself to prove that the intended live host, app-server, and thread/session are current, reachable, and authorized. That is the false-green state this issue should force the developer to account for during planning.

Note for this issue's developer: before planning, decide whether to incorporate this proposal into the issue's scope. Incorporating it means revising the review gate and desired state, using or adapting the issue-body form below. Choosing not to incorporate it means deferring it to a follow-up, rejecting it with rationale, or asking for clarification before an implementation plan is written.

Proposed issue-body edits for the incorporate branch:

## Review Gate

Run the `@codex-security` workflow before treating implementation as review-ready.

Review evidence must include a host-state matrix that verifies:

- The enrollment state shown in UI corresponds to current account/mobile enrollment state, not local UI plausibility alone.
- The intended host's app-server or managed remote-control daemon is alive and reachable.
- The Linux remote-control device key exists in the configured XDG device-key store with owner-only file permissions.
- The mobile side can see the intended host thread/session.
- A first mobile action or message is applied to the intended host thread/session.
- Stale, revoked, unauthorized, or mismatched hosts are rejected instead of displayed as connected.

## Desired State

- Fork-side UI patches expose Linux host plumbing without fabricating connected-client, MFA, enrollment, access-required, remote-environment, host-liveness, or thread/session state.
- Review evidence distinguishes OpenAI-hosted account/mobile authorization state from local generated-app UI state.
- Review evidence proves the first mobile-side action reaches the intended live host thread/session.

[nisavid]

This was generated by AI during triage.

This issue may proceed for non-visual security review, tests, and evidence gathering.

Any change to remote-control UI copy, settings layout, mobile setup flow, connected-state presentation, empty/error states, screenshots, or visual acceptance criteria is blocked on #91. Once PRODUCT.md and DESIGN.md are accepted, this issue should cite those docs and use their vocabulary and design constraints.

[nisavid]

This was generated by AI during triage.

Triage Notes

What we've established so far:

• The issue incorporates Snailflyer's host-state matrix as part of the review gate.
• PRODUCT.md and DESIGN.md now exist on main; UX-sensitive wording should use their vocabulary and constraints when touched.
• This issue can be worked as repo-local security review, docs, tests, and evidence gathering, but closure requires human-assisted live mobile/account verification.

Triage decision:

• Category: enhancement
• State: ready-for-human
• Rationale: the agent can prepare repo-local evidence and hardening, but an AFK agent cannot independently prove the mobile-side first action lands in the intended live host thread/session.

Agent brief:

• Scope: review and document the remote-control/mobile host boundary, add focused non-visual tests for any repo-local gaps, and record @codex-security findings plus mitigations.
• Do not close this issue unless the host-state matrix evidence is complete, including stale/revoked/unauthorized rejection and first mobile action applied to the intended host thread.
• Keep generated artifacts as inspection evidence only; durable fixes belong in source patchers, port integration tests, and maintained docs.