[Bug]: Codex tools fail to start when the scratch directory is symlinked on macOS#26051

Summary

Codex shell commands and Computer Use fail to start in a projectless scratch thread when T3's scratch directory is a symlink. On macOS, Codex rejects the symlinked workspace as a writable sandbox root.

Environment

• T3 Code Nightly 0.1.3-nightly.20261026.3726
• macOS 27.0, Apple Silicon
• Codex provider, workspace-write sandbox

Steps to reproduce

1. Set up ~/.t3/scratch as a symlink to an existing directory outside the T3 data directory.
2. Start a new projectless thread using Codex.
3. Ask it to run a shell command or use Computer Use.

Expected behavior

The tools start successfully using the scratch workspace, or T3 explains that this scratch configuration is unsupported and offers a way to use its real path.

Actual behavior

Both shell execution and Computer Use fail during sandbox setup, before the command or computer-control process starts. The error, with paths replaced by placeholders, is:

The error mentions allow_symlinked_codex_home, but says that setting applies only to roots at or beneath CODEX_HOME. This scratch folder is outside that location.

Investigation and scope

The installed T3 server constructs the scratch root from the T3 base directory using path.resolve(baseDir, "scratch"), which does not resolve filesystem symlinks. The failure was observed in an existing symlinked scratch setup; a separate clean-install reproduction has not been performed.

One possible direction is to resolve and validate the actual scratch workspace path before passing it to Codex, while preserving the intended sandbox boundary. This needs maintainer review and testing.

Related: #23727 and #23728 involve symlinked T3 paths during session import, but appear to address a different issue.

Workaround

A real, non-symlinked scratch directory may avoid this error; that workaround has not been tested in this installation.