Home Directory (`~`) Expansion in Unix Socket Paths

Open 💬 2 comments Opened Jun 24, 2026 by hoffmanr-cshs

What variant of Codex are you using?

App / CLI / IDE (local)

What feature would you like to see?

In developing a set of enterprise-managed permissions profile, we've run into a limitation with our ability to define unix sockets. For example, in an attempt to enable GPG signing of git commits, we would have wanted to do something like this:

# requirements.toml
[permissions.profile_name.network.unix_sockets]
"~/.gnupg/S.gpg-agent" = "allow"
"~/.gnupg/S.gpg-agent.extra" = "allow"
# or [experimental_network.unix_sockets] ...

But this is rejected, as the unix socket config seems to be expecting an absolute path:

$ codex resume
Error: Failed to resume session from [...]: thread/resume failed during TUI bootstrap:
thread/resume failed: error resuming thread: Fatal error: Failed to initialize session:
failed to start managed network proxy: failed to build network proxy state:
invalid network.allow_unix_sockets[0] (code -32603)

And for an enterprise-managed profile, needing to work across a variety of (potentially multi-user) systems, workarounds like moving/symlinking the socket to a hard-coded absolute path don't seem tenable.

Special-casing the expansion of a leading ~ in unix_socket paths would solve this specific issue. A more general solution might be supporting environment expansion in Codex configs, such as proposed in #2680.

Additional information

_No response_

View original on GitHub ↗

2 Comments

Nicolas0315 · 2 months ago

I put together a narrow fix for this on a fork branch:

https://github.com/openai/codex/compare/main...Nicolas0315:codex:codex/unix-socket-tilde-expansion?expand=1

Commit: Nicolas0315/codex@95d061b4b

What changed:

network.allow_unix_sockets validation now expands ~ and ~/... before enforcing the absolute-path requirement.
Relative paths remain rejected.
~user/... remains unsupported/rejected, so this is intentionally limited to the current user's home directory.
Added startup validation regressions plus a macOS runtime allowlist match test so an expanded absolute x-unix-socket path matches a ~/... allowlist entry.

Verification:

Local Windows: just fmt; just test -p codex-network-proxy; cargo check --manifest-path codex-rs\Cargo.toml -p codex-network-proxy; git diff --check
SSH rtx4090: just test -p codex-network-proxy (192 passed)
SSH cyberagent-mac-m5max: fresh clone + patch; focused resolve_runtime_; focused unix_socket_allowlist_expands_home_relative_entries; full cargo test --manifest-path codex-rs/Cargo.toml -p codex-network-proxy (198 passed)
SSH rtx5060ti: patch applied, Rust test blocked by linker/MSVC toolchain issue (link.exe resolves to an incompatible linker)
SSH nicolas2025: patch applied/static check, Rust blocked by zero-byte cargo/rustc
SSH nicolas-macbook-pro: patch applied, Rust blocked because Cargo is unavailable

I tried to open an upstream PR, but GitHub returned Nicolas0315 does not have the correct permissions to execute CreatePullRequest, so I’m leaving the compare link here.

boombx403-byte · 9 days ago

Hi @hoffmanr-cshs, the frozen history/resume behavior you described is one of the persistence patterns I've been studying. Codex Rescue Alpha5 includes a read-only projection consistency check that compares canonical rollout progress against stored projection cursors without touching SQLite.

If you still have the affected pre-repair session locally, you can test it with:

pip install codex-rescue==0.1.0a5
codex-rescue doctor --latest --json

(or point doctor directly to the rollout file). Please sanitize/redact any sensitive paths or names before sharing diagnostic output; raw session files are never needed.