fix: preserve deny-read sandboxing for safe commands

[bolinfest]

Why

Permission profiles can mark filesystem entries as unreadable with deny rules, including glob patterns. Several shell execution paths treated known-safe commands or execpolicy allow rules as sufficient to run outside the filesystem sandbox. That is not valid for read-capable commands: for example, cat or ls may be reasonable to allow generally, but dropping the sandbox would also drop deny-read constraints such as **/*.env.

What changed

• Added a shared check that treats active deny-read restrictions as incompatible with unsandboxed execution.
• Kept first-attempt execution sandboxed for explicit escalation and execpolicy allow bypasses when deny-read entries are present.
• Prevented no-sandbox retry after a sandbox denial when the active filesystem policy contains deny-read entries.
• Updated the zsh-fork execve path so prefix-rule allow decisions continue inside the current sandbox when deny-read restrictions are active.

Verification

• cargo test -p codex-core tools::sandboxing::tests
• cargo test -p codex-core tools::runtimes::shell::unix_escalation::tests
• cargo test -p codex-core shell_command_enforces_glob_deny_read_policy

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 101e4b3c61

ℹ️ 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".

[viyatb-oai]

Found one P2 regression in the deny-read plus zsh-fork approval flow; an inline suggested fix is attached.

[bolinfest]

@codex review

[viyatb-oai]

There is one remaining sibling regression in unified-exec zsh-fork after the shell-command fix; an inline suggested fix is attached.