Unrelated resume session with inaccessible cwd causes codex resume to hang

What version of Codex CLI is running?

0.122.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 resume hangs while loading the resume picker if old session history contains a saved cwd pointing at an unavailable/hung filesystem mount, even when Codex is launched from an unrelated accessible directory.

This is similar to #18771, but it is not the same bug. #18771 was about startup hanging because unrelated [projects] entries in config.toml were canonicalized. This happens later, in the resume/session history path. Normal Codex startup works, but codex resume never populates the resume table.

In my case, /mnt/protected is an NFS/autofs mount that is temporarily hanging when accessed after a power outage. I started Codex from /mnt/fast/..., which is local and accessible. codex resume opened the resume UI, showed Loading sessions..., and then never populated the table.

If I escape out of the picker and type /quit, the screen clears but Codex still does not return to the shell. This appears to be because a runtime worker is still stuck in a filesystem call.

What steps can reproduce the bug?

1. Have an old Codex session whose recorded cwd is under an unavailable mount, for example:

/mnt/protected/some/project

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 accessible directory:

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

1. The resume picker opens but stays stuck on Loading sessions....

I also tried:

codex resume --all

and it still hung, so this does not appear to be limited to filtering the resume list to the current cwd.

What is the expected behavior?

When the current working directory is accessible, and an unrelated historical session cwd will hang when accessed, codex resume should still show the resume list.

For codex resume --all, Codex should not need to canonicalize historical session cwd paths at all. The stored cwd can be shown as metadata without proving that the path still resolves.

For default codex resume, cwd matching can still be best-effort, but an inaccessible historical cwd should not block the picker from rendering or prevent Codex from exiting.

Additional information

Running under strace showed Codex blocked while trying to resolve an old session cwd:

readlink("/mnt/protected", ...) = -1 EINVAL
readlink("/mnt/protected/some_dir" <unfinished ...>)

The matching saved session metadata had:

cwd: /mnt/protected/some_dir/...

The likely issue is that resume/session listing or state DB repair/backfill canonicalizes saved historical cwd values. That is risky because old sessions may point at filesystems that are no longer mounted, are remote, or are currently wedged.

I understand the likely reason for canonicalization when filtering resumes to the current directory: Codex may want /some/path, a symlinked path, or another alias to match the same real directory. But this should be lazy/best-effort and should not be required for showing all resumes. If canonicalization hangs, Codex should fall back to string/path comparison, skip that historical cwd for filtered matching, or otherwise keep the UI responsive.