Skip to content

rollout: persist turn permission profiles#18281

Open
bolinfest wants to merge 1 commit intopr18280from
pr18281
Open

rollout: persist turn permission profiles#18281
bolinfest wants to merge 1 commit intopr18280from
pr18281

Conversation

@bolinfest
Copy link
Copy Markdown
Collaborator

@bolinfest bolinfest commented Apr 17, 2026

Why

Resume and reconstruction need to preserve the permissions that were active for each user turn. If rollouts only keep legacy sandbox fields, replay cannot faithfully represent profile-shaped overrides introduced earlier in the stack.

What changed

This records permission_profile on user-turn rollout events, reconstructs it through history/state extraction, and updates rollout reconstruction and related fixtures to keep the field explicit.

Verification

  • cargo test -p codex-core --test all permissions_messages -- --nocapture
  • cargo test -p codex-core --test all request_permissions -- --nocapture

Stack created with Sapling. Best reviewed with ReviewStack.

@bolinfest bolinfest force-pushed the pr18281 branch 2 times, most recently from 702cfbd to e2aa60f Compare April 17, 2026 17:52
@bolinfest bolinfest requested a review from a team as a code owner April 20, 2026 17:09
@bolinfest bolinfest force-pushed the pr18280 branch 2 times, most recently from ee0a15a to a56ac61 Compare April 21, 2026 00:47
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 pr18281 branch 2 times, most recently from 2997780 to e73d50e Compare April 21, 2026 05:15
@bolinfest bolinfest force-pushed the pr18280 branch 2 times, most recently from 0503105 to 5401f96 Compare April 21, 2026 05:49
@bolinfest bolinfest force-pushed the pr18281 branch 3 times, most recently from ff27339 to fd63861 Compare April 21, 2026 17:44
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