config: gate legacy writable roots from profiles

[bolinfest]

Why

The config loader still had a small profile-mode detour through SandboxPolicy: it projected the active PermissionProfile into a legacy sandbox policy only to ask whether the result looked like WorkspaceWrite before applying legacy writable_roots and memory-root additions.

That keeps legacy policy semantics in the middle of config loading even though the canonical runtime model is now PermissionProfile. This PR makes that decision from the canonical profile and its runtime filesystem policy instead.

What Changed

• Added a small helper that says legacy additional writable roots may extend only managed profiles that already grant write access to the active workspace.
• Replaced two temporary compatibility_sandbox_policy_for_permission_profile(...) projections in Config::load_config_with_layer_stack with that helper.
• Kept disabled, external, read-only, and full-disk profiles from silently growing legacy writable roots.
• Left the existing Config::legacy_sandbox_policy() compatibility projection in place for call sites that still need to speak the old API.

Verification

• cargo check -p codex-core --tests
• cargo test -p codex-core workspace_profile
• just fix -p codex-core

---

Stack created with Sapling. Best reviewed with ReviewStack.

• windows-sandbox: isolate allow path computation from legacy policy #20469
• docs: avoid stale SandboxPolicy references #20468
• config tests: assert sandbox-mode fallbacks via profiles #20467
• config tests: assert permission profile runtime state #20466
• config tests: derive permission profiles directly #20465
• tui tests: assert permission profiles directly #20459
• -> config: gate legacy writable roots from profiles #20456
• windows-sandbox: accept permission profiles from callers #20455
• exec: localize legacy Windows sandbox projection #20452
• session: stop exposing legacy sandbox policy #20450
• protocol: remove legacy sandbox turn-context overrides #20449
• protocol: drop legacy sandbox from user turns #20446
• protocol: require permission profiles for user turns #20441
• protocol: canonicalize turn context permissions #20440
• session: localize legacy sandbox turn fallback #20438
• rollout-trace: record permission profiles #20436
• protocol: make user-turn sandbox policy optional #20433
• session: tag turns with permission profiles #20432
• core tests: submit turns with permission profiles #20431
• turn-context: stop writing legacy sandbox policy #20430
• app-server: normalize command sandbox overrides as profiles #20429
• app-server: validate turn sandbox overrides as profiles #20428
• session: convert legacy sandbox updates before settings apply #20426
• sandboxing: exercise seatbelt with runtime policies #20424
• app-server: compare resume sandbox from permission profile #20423
• mcp: send sandbox metadata as permission profile only #20422
• thread-store: stop exposing legacy sandbox policy #20421
• tui: centralize legacy sandbox projection #20420
• test support: derive turn sandbox from permission profiles #20414
• windows setup: derive sandbox from permission profile #20412
• exec tests: derive thread sandbox from profile #20411
• windows read grants: accept permission profiles #20410
• session tests: configure permissions with profiles #20409
• analytics tests: derive sandbox fixtures from profiles #20408
• approval tests: configure scenarios with permission profiles #20407
• tui: hydrate thread permissions from profiles #20406
• rollout tests: seed turn contexts from permission profiles #20404
• state: extract rollout permissions from profiles #20403
• state: derive metadata sandbox from permission profiles #20401
• otel: report conversation permissions from profiles #20400
• protocol: drop cwd-less legacy profile constructor #20398
• app-server-test-client: select permission profiles by name #20397
• session tests: configure runtime permissions directly #20396
• tests: mutate spawn-agent permission profile directly #20394
• app-server tests: select turn permission profiles by name #20393
• file-system: drop unused legacy sandbox constructor #20390
• tests: use disabled profile in exec capture check #20389
• tests: use profile constructors in config checks #20388
• tests: use permission profiles in multi-agent config checks #20387
• tests: remove sandbox policy fixture from rollout trace #20386
• tests: use permission profiles in session network checks #20384
• tests: use permission profiles in config loader checks #20382
• tests: submit websocket turns with permission profiles #20381
• tests: use permission profiles in exec policy checks #20380
• tests: use permission profiles in request permission suite #20378
• tests: use permission profiles in unified exec suite #20376
• core: use permission profiles in small read-only contexts #20375
• exec tests: launch sandbox cases from permission profiles #20372
• tests: use permission profiles in suite turn submits #20370
• guardian: configure review session permissions directly #20369
• tests: use permission profiles in small core fixtures #20368
• exec-server: use permission profiles in file system handler tests #20367
• memories: configure consolidation permissions directly #20365
• analytics: distinguish custom managed permission profiles #20363
• tests: use permission profiles in guardian config checks #20362
• tests: use permission profiles in unix escalation checks #20360
• tests: use permission profiles in patch safety checks #20359
• tests: use permission profiles in tool sandbox tests #20358
• tests: use permission profile fixtures in config checks #20357
• core: build permission instructions from profiles only #20356
• utils: summarize permission profiles directly #20355
• tests: copy plugin stdio server before launch #20373

[chatgpt-codex-connector]

💡 Codex Review

codex/codex-rs/tui/src/app_server_session.rs

Lines 1414 to 1417 in 9348464

	// Current app-server responses include `permissionProfile`. If it is absent,
	// keep the TUI on its configured profile rather than rebuilding a lossy
	// profile from the legacy `sandbox` compatibility field.
	config.permissions.permission_profile()

Preserve remote sandbox fallback when permissionProfile is missing

When permissionProfile is absent in thread start/resume/fork responses, this now always falls back to the local config profile, but remote mode still derives future turn overrides from this stored profile. In version-skew or non-experimental responses where only legacy sandbox is populated, resuming a remote read-only thread can be silently rewritten to the local default (for example workspace-write) on the next turn. The previous remote fallback reconstructed permissions from sandbox, so dropping that path can change effective remote sandboxing and unexpectedly broaden write access.

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".