What version of Codex CLI is running?
0.107.0
What subscription do you have?
Pro
Which model were you using?
gpt-5.3-codex
What platform is your computer?
Linux (WSL2), workspace under /mnt/c/...
What terminal emulator and version are you using (if applicable)?
Windows Terminal + WSL2 shell (bash/zsh)
What issue are you seeing?
resume / fork now restores a lowercased working directory on WSL mounts (for example /mnt/c/users/name/project), even when the original path casing was /mnt/c/Users/Name/Project.
That lowercased restored cwd can break downstream behavior that is case-sensitive at the string layer (for example trust/workspace config checks and unified exec command/tooling integrations that expect canonical Windows-style casing).
This looks like a regression from the change to read cwd from SQLite metadata first during resume/fork. SQLite stores a normalized cwd (including WSL lowercasing), and that normalized value is now reused as the actual fallback cwd, not just for comparison.
Related prior fix: #7995 (case-insensitive matching on WSL). This report is about a new side effect: normalized lowercase path being used as the resumed execution cwd.
What steps can reproduce the bug?
- In WSL, open a repo from a mixed-case Windows-mounted path, for example:
cd /mnt/c/Users/Name/Project
- Start a session and do at least one turn so session metadata is persisted.
- Exit Codex.
- Resume or fork that session (
codex resume or codex fork) with SQLite enabled (default path).
- Inspect environment context / cwd used by the resumed session.
Observed: cwd can become a lowercased variant from normalized SQLite metadata (for example /mnt/c/users/name/project) instead of preserving original casing.
What is the expected behavior?
Resume/fork should preserve the original/usable cwd casing for execution context.
Path normalization should be used for equality/comparison only, not as the execution cwd that gets restored.
Additional information
Likely regression commit:
- c1afb8815af63c59b67824a73750884aa1a2e363 (tui: use thread_id for resume/fork cwd resolution) by @charley-oai
Relevant code points:
codex-rs/tui/src/lib.rs (read_session_cwd, resolve_cwd_for_resume_or_fork)
codex-rs/core/src/state_db.rs (normalize_cwd_for_state_db)
codex-rs/core/src/path_utils.rs (normalize_for_path_comparison, WSL /mnt/<drive> lowercasing)
Potential fix direction:
- Keep normalized cwd in SQLite for matching/indexing,
- but preserve/store an execution-display cwd separately (or reconstruct from rollout) for resume/fork fallback cwd selection.
Temporary Workaround
set
[features]
sqlite = false
in config.toml until this is fixed
What version of Codex CLI is running?
0.107.0
What subscription do you have?
Pro
Which model were you using?
gpt-5.3-codex
What platform is your computer?
Linux (WSL2), workspace under
/mnt/c/...What terminal emulator and version are you using (if applicable)?
Windows Terminal + WSL2 shell (
bash/zsh)What issue are you seeing?
resume/forknow restores a lowercased working directory on WSL mounts (for example/mnt/c/users/name/project), even when the original path casing was/mnt/c/Users/Name/Project.That lowercased restored cwd can break downstream behavior that is case-sensitive at the string layer (for example trust/workspace config checks and unified exec command/tooling integrations that expect canonical Windows-style casing).
This looks like a regression from the change to read cwd from SQLite metadata first during resume/fork. SQLite stores a normalized cwd (including WSL lowercasing), and that normalized value is now reused as the actual fallback cwd, not just for comparison.
Related prior fix: #7995 (case-insensitive matching on WSL). This report is about a new side effect: normalized lowercase path being used as the resumed execution cwd.
What steps can reproduce the bug?
cd /mnt/c/Users/Name/Projectcodex resumeorcodex fork) with SQLite enabled (default path).Observed: cwd can become a lowercased variant from normalized SQLite metadata (for example
/mnt/c/users/name/project) instead of preserving original casing.What is the expected behavior?
Resume/fork should preserve the original/usable cwd casing for execution context.
Path normalization should be used for equality/comparison only, not as the execution cwd that gets restored.
Additional information
Likely regression commit:
-
c1afb8815af63c59b67824a73750884aa1a2e363(tui: use thread_id for resume/fork cwd resolution) by @charley-oaiRelevant code points:
codex-rs/tui/src/lib.rs(read_session_cwd,resolve_cwd_for_resume_or_fork)codex-rs/core/src/state_db.rs(normalize_cwd_for_state_db)codex-rs/core/src/path_utils.rs(normalize_for_path_comparison, WSL/mnt/<drive>lowercasing)Potential fix direction:
Temporary Workaround
set
in config.toml until this is fixed