[zfy0701]

Summary

• allow a trusted ACP launcher to provide Codex app-server configuration overrides and map ACP modes to named permission profiles
• select the mapped profile when starting, resuming, or loading a thread, and update it when the ACP mode changes
• preserve additional workspace roots and omit the legacy per-turn sandbox policy while a named profile is active
• keep profile definitions opaque to codex-acp and preserve the existing behavior when no profile mapping is configured

Motivation

Named Codex permission profiles can express runtime policy that the legacy ACP sandboxPolicy cannot represent. ACP hosts need a launch-wide way to select those profiles consistently without making codex-acp own any operator-specific policy.

The launcher supplies CODEX_ACP_PERMISSION_PROFILE_CONFIG with app-server -c overrides and a complete mapping for the three ACP modes. codex-acp validates the mapping at startup, removes the launch variable from the Codex child environment, and uses the experimental app-server permission-profile fields for thread creation, resume, mode changes, and turns.

Compatibility

This is opt-in. Without CODEX_ACP_PERMISSION_PROFILE_CONFIG, codex-acp continues to send the existing per-turn sandbox policy unchanged. Invalid or incomplete profile mappings fail startup instead of silently weakening the requested policy.

Validation

• npm run typecheck
• npm test (342 passed, 28 skipped)
• npm run build
• Linux app-server smoke test covering session creation and all three ACP mode transitions
• Linux sandbox smoke test confirming that a profile-level file deny remained effective without a legacy per-turn sandbox override

Created by Codex . GPT-5.6

[humships]

We need this too, to keep a session's reads inside its project. Our app runs Codex as an agent in rooms other people can talk to. When someone other than the Mac's owner asks for something, Codex shouldn't be able to read the rest of the disk. Today codex-acp's Read-only policy reads everywhere, and we can't narrow it.

Checked with codex-acp 2.2.2 and codex 0.160.1:

• A profile set as default_permissions (in CODEX_CONFIG or config.toml) is replaced by the sandboxPolicy every turn sends. A Read-only turn still listed ~/projects. This is the same root cause as Default Agent prompts overwrite configured writable roots and sandbox permissions #477.
• The same profile holds when the turn sends no sandboxPolicy. Driving codex app-server directly, with the profile as the thread's default permissions and no per-turn policy, the turn read the workspace, and ~/.ssh/known_hosts and ~/projects came back Operation not permitted, without any approval prompt.
• A single launch-wide profile can follow each session's folder through :project_roots. {":minimal" = "read", ":project_roots" = "read", ":tmpdir" = "write"} let a session read its own working folder, and nothing in the home folder.

So a launcher-supplied mapping from modes to profiles is all we'd need: our launcher would map read-only to a profile like that one. Wrapping the adapter in an outer Seatbelt doesn't work, by the way. macOS refuses a second sandbox_apply inside a sandboxed process, so every command Codex runs fails, and it never asks to rerun it.

This branch conflicts with main now. I'm happy to rebase it, or test a rebased version on macOS, if that helps it land.