Codex search/grep tool processes run indefinitely with no timeout — orphaned rg floods network FS (Lustre/NFS)

Bug Description

Codex search/grep tools (launched by codex app-server --listen unix:// in code_mode_host mode) can run indefinitely with no timeout and no automatic kill — orphaned rg processes keep burning CPU/network I/O for 1+ hours on large projects (observed 46 min and 87 min).

On a cluster where the project lives on a network filesystem (Lustre/NFS), each file read is a network round-trip, so an unbounded recursive search produces sustained high-frequency small reads (measured ~72 RPC/s of 1-page reads at the Lustre client) and floods the storage network.

Steps to Reproduce

1. Run codex app-server (code_mode_host) against a large project tree on a network filesystem (e.g. Lustre).
2. Have the model issue a grep/search tool call (e.g. rg -n -C 3 PATTERN . or rg -n "a|b|c" <project_root>).
3. Without any explicit cancellation (close the session, or the request originates from app-server without a cancellation_token), observe:
   • The rg process keeps running for many minutes/hours.
   • ps shows it orphaned under codex app-server (PID chain: rg → codex app-server → sh → systemd).
   • No terminate/cancel is ever issued.

Observed on codex-cli 0.147.0:

• rg -n "济南|jinan|..." /xcfhome/llyu/project/FBP_binder/prot_design2 ran 46 minutes (started 09:40, still alive at 10:26) before eventually finishing.
• rg -n -C 3 LKQQLREYIRWEEAARNLLGLIE . ran 87+ minutes (still alive at time of writing).

Expected Behavior

• A server-side hard timeout on tool executions (search/grep/exec) — e.g. 60–120 s — after which the child process is killed automatically, even if no client cancellation arrives.
• Or: app-server (long-lived daemon) should reap/track children it spawned and kill them when the originating request/session is gone.

Actual Behavior

• No timeout exists in the search/exec path.
• Cancellation is client-owned only:
  • codex-rs/app-server/src/request_processors/search.rs: cancellation_token is optional — None => Arc::new(AtomicBool::new(false)) means "never cancel".
  • codex-rs/exec-server/src/server/handler.rs: terminate() is a passthrough — it is only invoked if the client explicitly calls it.
  • codex-rs/file-search/src/lib.rs: the walker checks the cancel flag only every CHECK_INTERVAL = 1024 entries.
• When the requesting session dies/disconnects, nothing kills the spawned child — it orphans under the long-lived codex app-server process.

Environment

• OS: RHEL 8 (kernel 4.18), x86_64
• Codex CLI: 0.147.0 (npm global)
• Filesystem: Lustre (network FS); also reproduces the general NFS-family slowness
• Home dir on network storage (no local SSD for project data)

Error Output

No error — the processes simply never exit:

$ ps -eo pid,etime,time,args | grep 'rg -n'
1417145  zpzeng  01:26:58  00:04:40  rg -n -C 3 LKQQLREYIRWEEAARNLLGLIE|LKQQLREY .
# ^ still running after 1h26m, parent = codex app-server (long-lived daemon)

$ cat /proc/fs/lustre/osc/*/rpc_stats   # client-side evidence of the small-read storm
1-page read RPCs: ~72/s sustained during the search

Additional Context

• Workaround used: manual kill of orphaned rg processes + a watchdog cron that kills search processes exceeding N minutes.
• Related code: codex-rs/app-server/src/fuzzy_file_search.rs (no timeout, cancel-only), codex-rs/exec-server/src/server/handler.rs (terminate is passthrough), codex-rs/file-search/src/lib.rs (cancel check every 1024 entries, follow_links(true), hidden(false)).
• The follow_links(true) + hidden(false) defaults also expand search scope on large trees (symlinked output dirs), compounding the problem.

Start by tracing the search path in codex-rs/app-server/src/fuzzy_file_search.rs and app-server/src/request_processors/search.rs, then inspect termination in codex-rs/exec-server/src/server/handler.rs and cancellation checks in codex-rs/file-search/src/lib.rs. Reproduce an uncancelled search and verify that tool processes are bounded or cleaned up when a request or session ends, including on large network-backed trees.