Approach check: stop sending a per-turn Codex sandboxPolicy that clobbers launch arguments (#14369)

[IzonIcy]

Posting ahead of review per CONTRIBUTING's "Discuss Changes First" — happy to be redirected here before you spend time on the diff.

PR: #14369 · Issue: #13987 (reported by @famesjranko, not by me)

The bug

buildTurnStartParams sent a sandboxPolicy on every Codex turn, built from the runtime mode alone. The Codex app-server schema documents that field as "Override the sandbox policy for this turn and subsequent turns" and defaults a missing networkAccess to false and writableRoots to [].

So the per-turn policy replaced the thread policy that carried the user's launch arguments. Setting -c sandbox_workspace_write.network_access=true in T3's Launch arguments had no effect in any sandboxed mode, and neither did any other configured sandbox setting.

The approach

Remove the field, delete the now-unused runtimeModeToTurnSandboxPolicy. Net -22 lines, no new code.

It's safe because the runtime mode is already applied once per session on both paths in openCodexThread — thread/start at :731, and thread/resume at :740, which spreads the same buildThreadStartParams output. The per-turn field was re-asserting a value the session had just been started with.

Mid-session mode changes are unaffected: ProviderCommandReactor handles thread.runtime-mode-set by restarting the session, and the generated client has no thread/settings/update RPC, so restart-on-change is the only available mechanism and it already exists.

The alternative I rejected

Read the thread's effective sandbox back from the thread/start response and echo it with only the type changed. That needs CodexThreadResumeMetadata widened plus a value threaded through four touchpoints, and it rests on an assumption nothing in this repo proves — that the response actually reflects the -c config merge. Deleting the field has no such dependency.

What I want feedback on

approvalPolicy and approvalsReviewer have the same defect and are still broken. Both are sent per turn, and the schema documents them with the same override semantics, so -c approval_policy=... in launch arguments is clobbered exactly the same way. I deliberately did not fix them here — it's a larger behavioral change and I read it as its own PR. If maintainers would rather see all three removed together, say so and I'll widen this.

Antigravity re-applies its mode before every turn (AntigravityAdapter.ts:1072, in addition to session start at :850). Structurally the same bug class, different mechanism — ACP setMode rather than a JSON-RPC field. Not touched. Worth knowing it exists if you'd rather treat this as one cross-provider cleanup than three PRs.

Four existing cases asserted the whole params object and had the key removed from their expectations; one new regression test covers both sandboxed modes. I confirmed all five fail against the unfixed source.

Full validation commands are in the PR.