Skip to content

feat(sandbox): support launch-configured permission profiles - #357

Open
zfy0701 wants to merge 1 commit into
agentclientprotocol:mainfrom
agentconnect-md:codex/launch-configured-permission-profiles
Open

feat(sandbox): support launch-configured permission profiles#357
zfy0701 wants to merge 1 commit into
agentclientprotocol:mainfrom
agentconnect-md:codex/launch-configured-permission-profiles

Conversation

@zfy0701

@zfy0701 zfy0701 commented Aug 2, 2026

Copy link
Copy Markdown

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

@zfy0701 zfy0701 mentioned this pull request Aug 2, 2026
Closed
@tpansino tpansino mentioned this pull request Aug 12, 2026
Merged
@madawei2699 madawei2699 mentioned this pull request Sep 7, 2026
Closed
8 tasks done
@Automaat Automaat mentioned this pull request Oct 10, 2026
Closed
@humships

humships commented Oct 19, 2026

Copy link
Copy Markdown

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.

EugeneTheDev pushed a commit that referenced this pull request Nov 3, 2026
@tpansino
feat: expose configured permission profiles as modes (#395)
caf2e87 
## Summary

Implements #519.

- List allowed, user-defined Codex permission profiles using
`permissionProfile/list`
- Expose those profiles in ACP mode selectors, including their
configured descriptions
- Restore the active profile when starting or resuming a session
- Send named profiles through `turn/start` without combining them with
legacy sandbox policies
- Preserve additional workspace roots and the effective approval policy
- Keep the existing read-only, agent, and full-access modes unchanged

Built-in and disallowed profiles are omitted from the additional profile
entries.

Related to #310.

PR #357 maps the existing fixed ACP modes to configured profiles. This
change instead discovers allowed custom profiles dynamically and exposes
them as selectable ACP modes.

## Testing

- `npm run typecheck`
- `npm test` — 404 passed, 28 skipped
- `npm run build`
- Native macOS ARM bundle
- Real Codex 0.147 app-server profile discovery and selection
- End-to-end Zed test with a custom permission profile

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

2 participants

@zfy0701 @humships