Skip to content

app-server: accept command permission profiles#18283

Open
bolinfest wants to merge 1 commit intopr18282from
pr18283
Open

app-server: accept command permission profiles#18283
bolinfest wants to merge 1 commit intopr18282from
pr18283

Conversation

@bolinfest
Copy link
Copy Markdown
Collaborator

@bolinfest bolinfest commented Apr 17, 2026

Why

command/exec is another app-server entry point that can run under caller-provided permissions. It needs to accept PermissionProfile directly so command execution is not left behind on SandboxPolicy while thread APIs move forward.

What changed

This adds permissionProfile to CommandExecParams, rejects requests that combine it with sandboxPolicy, converts the profile into execution permissions, updates app-server docs/schema fixtures, and adds command-exec coverage for both the accepted and rejected paths.

Verification

  • cargo test -p codex-app-server command_exec_accepts_permission_profile -- --nocapture
  • cargo test -p codex-app-server command_exec_rejects_sandbox_policy_with_permission_profile -- --nocapture

Stack created with Sapling. Best reviewed with ReviewStack.

@bolinfest bolinfest force-pushed the pr18282 branch 2 times, most recently from bc7e463 to 41ebc4d Compare April 17, 2026 17:08
@bolinfest bolinfest force-pushed the pr18283 branch 2 times, most recently from 8b4d2a2 to e5f2e57 Compare April 17, 2026 19:33
@bolinfest bolinfest force-pushed the pr18283 branch 2 times, most recently from a9a5407 to e600010 Compare April 20, 2026 18:35
bolinfest added a commit that referenced this pull request Apr 21, 2026
## Why

#18274 made `PermissionProfile` the canonical file-system permissions
shape, but the round-trip from `FileSystemSandboxPolicy` to
`PermissionProfile` still dropped one piece of policy metadata:
`glob_scan_max_depth`.

That field is security-relevant for deny-read globs such as `**/*.env`.
On Linux, bubblewrap sandbox construction uses it to bound unreadable
glob expansion. If a profile copied from active runtime permissions
loses this value and is submitted back as an override, the resulting
`FileSystemSandboxPolicy` can behave differently even though the visible
permission entries look equivalent.

## What changed

- Add `glob_scan_max_depth` to protocol `FileSystemPermissions` and
preserve it when converting to/from `FileSystemSandboxPolicy`.
- Keep legacy `read`/`write` JSON for simple path-only permissions, but
force canonical JSON when glob scan depth is present so the metadata is
not silently dropped.
- Carry `globScanMaxDepth` through app-server
`AdditionalFileSystemPermissions`, generated JSON/TypeScript schemas,
and app-server/TUI conversion call sites.
- Preserve the metadata through sandboxing permission normalization,
merging, and intersection.
- Carry the merged scan depth into the effective
`FileSystemSandboxPolicy` used for command execution, so bounded
deny-read globs reach Linux bubblewrap materialization.

## Verification

- `cargo test -p codex-sandboxing glob_scan -- --nocapture`
- `cargo test -p codex-sandboxing policy_transforms -- --nocapture`
- `just fix -p codex-sandboxing`





---
[//]: # (BEGIN SAPLING FOOTER)
Stack created with [Sapling](https://sapling-scm.com). Best reviewed
with [ReviewStack](https://reviewstack.dev/openai/codex/pull/18713).
* #18288
* #18287
* #18286
* #18285
* #18284
* #18283
* #18282
* #18281
* #18280
* #18279
* #18278
* #18277
* #18276
* #18275
* __->__ #18713
@bolinfest bolinfest force-pushed the pr18283 branch 3 times, most recently from e28c7f4 to 76a5cf7 Compare April 21, 2026 05:31
@bolinfest bolinfest force-pushed the pr18282 branch 2 times, most recently from e17a9a2 to f4b6873 Compare April 21, 2026 06:18
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant