feat(exec-server): canonicalize executor paths [1 of 6]

[fcoury-oai]

Why

Workspace mutations must canonicalize paths through the selected execution environment. Resolving a remote path on the app-server host would validate the wrong filesystem and could persist an invalid access boundary.

What Changed

• Add canonicalize(path) to the executor filesystem abstraction.
• Add the fs/canonicalize exec-server RPC and route it through local, sandboxed, and remote filesystem implementations.
• Preserve sandbox context while resolving canonical paths.

How to Test

1. Run the exec-server filesystem tests.
2. Confirm a local symlink resolves to its canonical target.
3. Confirm the remote filesystem implementation sends fs/canonicalize over RPC instead of resolving the path on the host.

Targeted tests:

• direct_file_system_canonicalizes_symlinks
• fs_canonicalize_uses_remote_rpc

Stack

1. feat(exec-server): canonicalize executor paths [1 of 6] #25337 executor path canonicalization (this PR)
2. #25336 runtime workspace state
3. #25339 ordered mutation barriers
4. #25334 model workspace tools
5. #25338 approval projection
6. #25335 TUI workspace commands

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 0db653e858

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

[MisterRound]

Linking related Windows Desktop + WSL context from #25317 / #25370 because this PR touches executor path canonicalization.

This canonicalization work may be useful for workspace mutations, but it should not be treated as fixing the current WSL shell/tool regression. In #25317, the workspace path exists and canonicalization is not the failing boundary. The broken state is a stale PATH entry to a deleted %USERPROFILE%/.codex/tmp/arg0/codex-arg0* helper dir, with the live WSL app-server still holding an fd/lock to the deleted helper path.

The deeper issue is cross-runtime helper ownership: Windows-native Codex/plugin paths and the WSL app-server can share the same tmp/arg0 namespace, and the Windows-native path has been observed deleting a repaired WSL helper dir. That needs an arg0 lifecycle/runtime-family fix, not only executor workspace path canonicalization.