Conversation
bolinfest
changed the title
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 11750256e8
ℹ️ 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".
| workspace_root_writable = true; | ||
| } else { | ||
| writable_roots.push(path.clone()); | ||
| unbridgeable_external_write = true; |
There was a problem hiding this comment.
When a materialized workspace profile contains both cwd and an additional workspace root (for example from --add-dir/workspaceRoots), this branch records the non-cwd write as unbridgeable_external_write but still returns WorkspaceWrite as soon as cwd is writable. Because WorkspaceWrite no longer carries writable_roots, the compatibility policy only exposes cwd; I checked resolve_windows_restricted_token_filesystem_overrides, which compares those legacy roots with the split filesystem roots and returns windows unelevated restricted-token sandbox cannot enforce split writable root sets on mismatch. This regresses Windows restricted-token runs with additional workspace roots that used to be representable via writable_roots.
Useful? React with 👍 / 👎.
| active_permission_profile, | ||
| cwd, | ||
| cwd: cwd.clone(), | ||
| workspace_roots: vec![cwd], |
There was a problem hiding this comment.
ThreadStartResponse and ThreadResumeResponse now include the server's effective workspace_roots, but the exec bootstrap event is still hard-coded to vec![cwd]. In codex exec sessions started/resumed with additional roots, the rollout's SessionConfiguredEvent drops those roots; later resume/fork reconstructs permission state from that event and materializes :project_roots with only cwd, so previously writable --add-dir roots are lost. Pass the response roots through here, falling back to cwd only when the response is empty.
Useful? React with 👍 / 👎.
…permission profile modifications as an overlay for writable roots. Existing app-server threads now preserve their persisted PermissionProfile value across resume, fork, and turn updates; permissions requests on existing threads only update the active named profile after validating it exists. Workspace roots can be updated independently, and SandboxPolicy::WorkspaceWrite no longer stores its own writable_roots.
2 participants
Why
Codex is moving permission state from the legacy
SandboxPolicyabstraction toPermissionProfile. For existing threads, the actualPermissionProfilevalue should be durable thread state, not something an app-server client can rewrite through resume, fork, or turn APIs. The active profile name and workspace roots are separate thread state: the name is UI/selection metadata, while workspace roots define how symbolic:project_rootspermission entries materialize for that thread.This separation removes the need for
ActivePermissionProfileModification, which was effectively an overlay that let roots mutate the active profile. Roots now live with the thread instead of being carried inside the active profile or insideSandboxPolicy::WorkspaceWrite.What changed
workspace_rootsstate and persisted it through rollout, thread-store metadata, app-server lifecycle responses, and turn context.thread/resume,thread/fork, andturn/startso existing threads preserve their persistedPermissionProfilevalue.permissionssupport on existing app-server threads as active-profile-name selection only, with validation that unknown profile ids return a JSON-RPC error.workspaceRootsto update independently fromcwd; cwd-only updates preserve the existing root list.ActivePermissionProfileModification/PermissionProfileModificationParamsfrom protocol models and generated TypeScript exports.SandboxPolicy::WorkspaceWriteso it no longer ownswritable_roots; v2 still accepts legacywritableRootson deserialization for compatibility and ignores them.workspace_roots, and removed the now-unusedcodex-utils-sandbox-summarydev dependency.Verification
cargo test -p codex-core --libcargo test -p codex-core --test all personality_migrationcargo test -p codex-app-server-protocolcargo test -p codex-protocolcargo test -p codex-app-servercargo test -p codex-statecargo test -p codex-analyticscargo test -p codex-thread-manager-samplecargo shearjust argument-comment-lintjust fix -p codex-corejust fix -p codex-state -p codex-analytics -p codex-thread-manager-samplejust bazel-lock-updatejust bazel-lock-check