Unrelated project in config.toml with inaccessible directory causes immediate hang

What version of Codex CLI is running?

0.121.0

What subscription do you have?

Plus

Which model were you using?

gpt-5.4 high

What platform is your computer?

Linux 6.19.11-arch1-1 x86_64 unknown

What terminal emulator and version are you using (if applicable)?

n/a

What issue are you seeing?

Codex immediately hangs on startup if ~/.codex/config.toml contains saved [projects."<path>"] trust entries pointing at an unavailable/hung filesystem mount, even when Codex is launched from an unrelated current directory.

If I was starting Codex to use a hung path, I wouldn't really have a problem with Codex silently hanging as that's pretty standard behavior for programs and should be easily discoverable by the user. The issue is that a user isn't going to expect a completely unrelated project, perhaps one they haven't used for a very long time, to cause the hang.

In my case, /mnt/protected is an NFS/autofs mount that is temporarily hanging when being accessed after a power outage. I started Codex from /mnt/fast/something which is local and accessible, but Codex never printed anything. (It hangs on the blank line after the terminal line where I started codex.) Starting with a fresh home directory using CODEX_HOME=$HOME/.codex.new worked.

What steps can reproduce the bug?

1. Have a ~/.codex/config.toml entry like:

[projects."/mnt/protected/some/project"]
trust_level = "trusted"

1. Make /mnt/protected unavailable in a way where filesystem calls hang, e.g. a hard NFS mount waiting on an offline server.

1. Start Codex from an unrelated directory:

cd /mnt/fast/some/working/repo
codex

1. Codex hangs before printing anything at all.

What is the expected behavior?

When the current (or given) working directory is accessible, and an unrelated trusted project directory will hang when accessed, Codex should start normally.

Additional information

A user has no way to tell what is causing Codex to hang unless they run strace or have Codex build and investigage itself. Like any program trying to access a hung NFS mount, CTRL+C and CTRL+Z don't kill/suspend it. A user has to kill -9 Codex.

Starting with strace showed Codex was blocked before normal logging/state initialization while canonicalizing saved project trust entries. The relevant code appears to be in project_trust_context, where every configured project is mapped through project_trust_key, and project_trust_key calls dunce::canonicalize.

I understand the likely reason for canonicalization, wanting single paths to map to the same trust entry.

I haven't gotten into the exact reasons for and impacts from doing this, so I don't have a proposed fix. Maybe canonicalizing all projects can be done lazily. Maybe projects on other mountpoints than the project being opened don't need to be canonicalized. Maybe a child process can be spawned to run commands on each path being canonicalized, so if one doesn't return quickly the main thread could continue. (The child process might remain stuck.)

Yes, there are other NFS configurations that don't wait indefinitely if an NFS server is down, rebooting, unreachable, or in a bad state, but a hard mount option is not unusual. I'm sure other users have had hangs just like this and never figured out what was causing it.