app-server: accept command permission profiles

[bolinfest]

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.

Command-level profiles also need to preserve the semantics clients expect from profile-relative paths. :cwd and cwd-relative deny globs should be anchored to the resolved command cwd for a command-specific profile, while configured deny-read restrictions such as **/*.env = none still need to be enforced because they can come from config or requirements rather than the command override itself.

What Changed

This adds permissionProfile to CommandExecParams, rejects requests that combine it with sandboxPolicy, and converts accepted profiles into the runtime filesystem/network permissions used for command execution.

When a command supplies a profile, the app-server resolves that profile against the command cwd instead of the thread/server cwd. It also preserves configured deny-read entries and globScanMaxDepth on the effective filesystem policy so one-off command overrides cannot drop those read protections. The PR also updates app-server docs/schema fixtures and adds command-exec coverage for accepted, rejected, cwd-scoped, and deny-read-preserving profile paths.

Verification

• cargo test -p codex-app-server command_exec_permission_profile_cwd_uses_command_cwd
• cargo test -p codex-app-server command_profile_preserves_configured_deny_read_restrictions
• cargo test -p codex-app-server command_exec_accepts_permission_profile
• cargo test -p codex-app-server command_exec_rejects_sandbox_policy_with_permission_profile
• just fix -p codex-app-server

---

Stack created with Sapling. Best reviewed with ReviewStack.

• tests: isolate approval fixtures from host rules #18288
• shell-escalation: carry resolved permission profiles #18287
• mcp: include permission profiles in sandbox state #18286
• tui: carry permission profiles on user turns #18285
• tui: sync session permission profiles #18284
• -> app-server: accept command permission profiles #18283

[viyatb-oai]

[P1] Resolve command permission profiles against the command cwd

command/exec resolves the requested process cwd above, but this new permissionProfile path still materializes profile entries against self.config.cwd via sandbox_cwd. The command API docs show permissionProfile using current_working_directory next to the request cwd, and profiles can also carry cwd-relative deny globs. With the current code, a command running in cwd: "subdir" with :cwd write grants the server root instead of the command cwd, while relative deny globs constrain the wrong tree. That can deny the intended command or grant broader writes than the client requested. Use the resolved command cwd as the policy cwd for command-specific permission profiles, or require/materialize only cwd-independent profile entries before accepting them.

[viyatb-oai]

Suggested minimal patch:

-        let sandbox_cwd = self.config.cwd.clone();
+        let sandbox_cwd = if permission_profile.is_some() {
+            cwd.clone()
+        } else {
+            self.config.cwd.clone()
+        };

That keeps the legacy/default command/exec paths resolving policy-relative entries against the configured server cwd, while making the new command-specific permissionProfile path use the resolved process cwd for both to_legacy_sandbox_policy(...) and the later build_exec_request(...) call.