What version of Codex CLI is running?

0.113

What subscription do you have?

ChatGPT Pro

Which model were you using?

gpt-5.4

What platform is your computer?

Linux (WSL2), workspace under /mnt/c/Users/...

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

Windows Terminal + WSL2 shell (bash/zsh)

What issue are you seeing?

The WSL resume/fork cwd regression from #13337 is still present in the current codebase, and after fa16c26908cd6881f03e6484fb60d20c1ad63a53 users can no longer work around it by disabling SQLite.

The failure mode is:

• a session started in /mnt/c/Users/Name/Project
• SQLite stores a normalized cwd for matching/comparison
• resume / fork then reuses that normalized value as the actual execution cwd
• on WSL that can become /mnt/c/users/name/project

That lowercased restored cwd can break behavior that is case-sensitive at the string layer, including unified exec/sandbox/trust/workspace config resolution and command/tool integrations that expect the usable Windows-mounted path casing.

Issue #13337 was closed with the note that #13336 would fix it, but #13336 did not address the execution-cwd path. It normalized DB storage more consistently; it did not stop resume / fork from returning metadata.cwd from SQLite as the resumed cwd.

What steps can reproduce the bug?

1. In WSL, cd into a mixed-case Windows-mounted repo path such as:
   • cd /mnt/c/Users/Name/Project
2. Start Codex and perform at least one turn so session metadata is persisted.
3. Exit Codex.
4. Resume or fork that session on current main.
5. Inspect the cwd used by the resumed session.

Observed:

• the resumed cwd can be the lowercased SQLite-normalized form such as /mnt/c/users/name/project
• fa16c26908cd6881f03e6484fb60d20c1ad63a53 removed the sqlite feature flag, so the old workaround

[features]
sqlite = false

is no longer available. See below for new workaround.

What is the expected behavior?

resume / fork should preserve a usable execution cwd with the original casing, while normalization should be used only for matching/comparison.

Removing the SQLite opt-out should not make WSL resume/fork permanently restore a lowercased execution cwd.

Additional information

Relevant history:

• CLI: resume/fork on WSL can restore lowercased cwd from SQLite-normalized path #13337 reported this exact WSL lowercased-cwd behavior
• fix: db windows path #13336 (938c6dd3880c3a38708e0b1d2bbe54dc2fe10683) normalized DB/backfill storage, but did not fix resume/fork execution cwd restoration
• fa16c26908cd6881f03e6484fb60d20c1ad63a53 removed the sqlite feature flag and with it the only practical workaround

Current code path showing the issue:

• codex-rs/core/src/state_db.rs: normalize_cwd_for_state_db(...) stores normalized cwd
• codex-rs/core/src/rollout/metadata.rs: backfill now also normalizes cwd before upsert
• codex-rs/tui/src/lib.rs: read_session_cwd(...) returns SQLite metadata.cwd first
• codex-rs/tui/src/lib.rs: resolve_cwd_for_resume_or_fork(...) uses that returned value as the fallback resumed cwd

This looks like the fix needs to separate:

1. normalized cwd for equality/indexing
2. original/display/execution cwd for actual resume/fork working directory restoration

Current workaround

Passing an explicit cwd on resume/fork still works as a manual escape hatch:

codex resume <SESSION_ID> -C /mnt/c/Users/Name/Project
codex fork <SESSION_ID> -C /mnt/c/Users/Name/Project

That is not a real fix, because users have to remember to override the cwd every time, but it does avoid inheriting the lowercased SQLite-normalized path.