fix(codex): select compatible transports on agent launch

[mjaggard]

Agent restarts currently attach --remote to Codex invocations that also carry permission overrides and hive --add-dir grants. Codex rejects remote resume permission overrides, and rejects --add-dir on remote launches, so these agents can exit before resuming their work.

Choose the transport before starting or enabling a managed daemon. Incompatible launches run with --no-daemon, preserving the session ID, prompt, approval policy, sandbox and writable directories. Compatible fresh launches and resumes retain managed remote access. For fresh launches explicitly requesting full sandbox bypass, omit redundant directory grants so remote access remains possible. Honour explicitly selected --remote and --no-daemon transports.

Refs #642. This addresses the launch rejection; the separately reported disappearance from the roster has not been reproduced or changed.

How I tested it

OS: macOS; Codex CLI 0.160.1.

Validation:

• 50 tests passed across Codex remote, provider registry/configuration/automation and worker launch suites.
• npm run typecheck and npm run build passed.
• Full suite (npm run test:focused -- --test-timeout=20000): 969 passed, 1 skipped, 1 failed. The failure is the existing shipped/baked model-catalogue mismatch (test/model-catalog-remote.test.cjs:60); the test, parser, renderer config and both JSON inputs are identical to origin/main. The initial unbounded run stalled, so the completed run used explicit timeouts.
• With installed Codex 0.160.1, a local resume containing Auto Mode, hive writable-root and hook-trust options reached session lookup and returned the expected error for a deliberately nonexistent session ID, without a permission-override rejection. No model turn was run.

Limitations: default sandboxed hive launches still need --add-dir, so they run locally and lack mobile remote access. Preserving remote access for those launches requires a separate server-side writable-root integration. End-to-end resume of an existing session and mobile visibility have not been tested; compatibility with older Codex versions has not been established.

Evidence

These are rendered captures of the same launch-argument regression against origin/main and this branch, not application screenshots or evidence of mobile connectivity. Reproduction script and instructions.

Before

The old launch helper selects remote transport while retaining permission overrides and extra directory grants. The regression fails.

After

The same arguments select local execution while retaining the session ID, permissions and writable hive path (including spaces). The regression passes.

[github-actions]

✅ Evidence received. Before and after are both attached. Thanks — this is what makes a PR reviewable in one pass.

[mjaggard]

I have compared this PR with #625, and I would recommend retaining both as complementary fixes. Thank you to the author of #625 for tackling the separate read-only launch failure and providing Windows validation.

For #642 specifically, #705 addresses the restriction that #625 does not change: remote resume cannot accept permission overrides. In workspace-write mode, #625 intentionally retains the hive’s --add-dir grants, and the existing launcher still selects --remote. That leaves both the remote-resume permission conflict and the remote transport’s rejection of --add-dir unresolved. #705 instead selects --no-daemon when the launch is incompatible with remote mode, preserving the session, permissions and writable roots. It retains managed remote access for compatible launches.

Conversely, #625’s read-only root gate is valuable and is not implemented here. Keeping --add-dir and switching to local execution does not resolve a sandbox that disallows additional writable roots, so #705 should not be presented as a complete replacement for #625.

I applied #625’s patch to this branch in an isolated worktree: it applied cleanly, and the combined Codex suites passed all 25 tests. This verifies the patches together at the code/test level; existing-session resume and mobile visibility remain untested end to end. The local fallback’s loss of mobile access remains an explicit limitation.

On that basis, I am leaving #705 open for the remote-launch failure in #642, alongside #625’s separate sandbox correction.