fix: handle deferred network proxy denials

[viyatb-oai]

Why

This bug is exposed by Guardian/auto-review approvals. With the managed network proxy enabled, a blocked network request can be reported back through the network approval service as an approval denial after the command has already started. Before this change, the shell and unified exec runtimes registered those network approval calls, but did not have a way to observe an async proxy denial as a cancellation/failure signal for the running process.

The result was confusing: Guardian/auto-review could correctly deny network access, but the command path could keep running or unregister the approval without surfacing the denial as the command failure.

What Changed

• NetworkApprovalService now attaches a cancellation token to active and deferred network approvals.
• Proxy-denial outcomes are recorded only for active registrations, cancel the owning token, and are consumed when the approval is finalized.
• The shell runtime combines the normal command timeout with the network-denial cancellation token.
• Unified exec stores the deferred network approval object, terminates tracked processes when the proxy denial arrives, and returns the denial as a process failure while polling or completing the process.
• Tool orchestration passes the active network approval cancellation token into the sandbox attempt and preserves deferred approval errors instead of silently unregistering them.
• App-server command/exec now handles the combined timeout-or-cancellation expiration variant used by the runtime.

Verification

• cargo test -p codex-core network_approval --lib
• cargo clippy -p codex-app-server --all-targets -- -D warnings
• cargo clippy -p codex-core --all-targets -- -D warnings

[dylan-hurd-oai]

generally looks good, but i'd like @jif-oai to look at unified exec. would be great to have slightly more detail in the denial messages

[dylan-hurd-oai]

I think we're okay to proceed for now, but would like the denial messages to be a bit clearer about where the network access denial is coming from. I think lack of specificity will lead to model confusion here

[jif-oai]

Unified exec still builds ExecOptions { expiration: ExecExpiration::DefaultTimeout, ... } without wiring attempt.network_denial_cancellation_token into the spawned request. The manager-side watcher covers the normal process after spawn, but anything inside the spawn/ preparation path, especially zsh-fork escalation setup, is not cancelled through the same expiration path as shell commands. That makes unified exec less robust than the shell path added in this PR.

[viyatb-oai]

@codex review

[chatgpt-codex-connector]

💡 Codex Review

codex/codex-rs/app-server/src/command_exec.rs

Lines 540 to 547 in 62cf07c

	_ = &mut expiration, if !timed_out => {
	timed_out = true;
	session.request_terminate();
	}
	exit = &mut exit_rx => {
	if timed_out {
	break EXEC_TIMEOUT_EXIT_CODE;
	} else {

Distinguish cancellation from timeout in command/exec

TimeoutOrCancellation now feeds this expiration arm, but the branch always sets timed_out = true; later exit handling maps any such termination to EXEC_TIMEOUT_EXIT_CODE. Cancellation-triggered stops (including network-denial cancellations) are therefore mislabeled as timeouts in responses.

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

[jif-oai]

This makes denial cancellation work only when exactly one network-backed command is active. Can't we have to live execs? (or more ofc)

[viyatb-oai]

Yes. Multiple live network-backed commands are possible. right now the proxy observer gives us an unattributed BlockedRequest, so this path only cancels when exactly one active call exists; with multiple active calls we cannot safely know which registration to fail, and intentionally avoid canceling the wrong one.

I've tried to fix this before but it ends up being a messy fix in the proxy code with registration/call ids in the headers and its brittle (an id via proxy credentials in the proxy URL).
I'll call this out explicitly in the code.