Track remaining PathUri migration across shell/tools subsystems

Open 💬 0 comments Opened Jul 18, 2026 by trac3r00

[Bob] Problem

There are 8 scattered TODO comments across codex-rs/core/src/ for migrating various subsystems to use PathUri instead of raw string paths. These are all authored by the same developer (anp) and represent a single coherent migration that has stalled partway:

| File | Line | Scope |
|---|---|---|
| tools/runtimes/shell/unix_escalation.rs | 181 | Shell escalation boundary |
| tools/runtimes/shell/unix_escalation.rs | 185 | Sandbox policy boundary |
| tools/runtimes/shell/unix_escalation.rs | 292 | zsh-fork executor boundary |
| tools/runtimes/shell/unix_escalation.rs | 297 | zsh-fork sandbox policy boundary |
| tools/runtimes/shell/unix_escalation.rs | 1057 | execve-wrapper boundary |
| tools/runtimes/unified_exec.rs | 310 | Shell snapshot lookup |
| tools/handlers/extension_tools.rs | 120 | Extension ToolEnvironment |
| tools/handlers/request_permissions.rs | 76 | Permission parsing/profiles |

Impact

Until these are migrated, foreign (non-local) paths silently skip sandbox/permission checks in several code paths (e.g. apply_patch.rs:316 explicitly notes this). This is a correctness gap for remote backend scenarios.

Proposed solution

Track this as a single migration issue rather than 8 independent fixes. The migration pattern is consistent — replace &str/String path parameters with PathUri, update callers, and remove the skip-foreign fallbacks.

Happy to take a subset of these if the team wants to parallelize.

View original on GitHub ↗