Resume does not restore the same project context as a fresh session in WSL (project-local MCP/skills diverge, `$` skill picker becomes empty)

What version of Codex CLI is running?

0.120.0

What subscription do you have?

Paid ChatGPT plan (exact tier omitted for privacy)

Which model were you using?

gpt-5.4 xhigh

What platform is your computer?

WSL on Windows; workspace located on a mounted /mnt/<drive>/... path

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

WSL terminal (exact emulator/version omitted for privacy)

What issue are you seeing?

In a WSL workspace on a mounted Windows drive, resuming an old Codex session does not restore the same effective project context as starting a fresh session in the same directory.

The most visible symptoms are:

• project-local MCP behavior diverges from a fresh session
• the $ skill picker in the TUI becomes empty after resuming an older session
• a fresh session in the same workspace still shows system skills normally
• explicit skill invocation can still work even when the $ picker is empty

This appears to be resume-specific state restoration behavior rather than a missing config or missing skill file on disk.

What steps can reproduce the bug?

1. Use Codex CLI from WSL in a repository stored on a mounted Windows drive, for example under /mnt/<drive>/Program/<repo>.

1. Add a project-local .codex/config.toml with at least one project-local MCP server.

1. Optionally add a project-local skill under .codex/skills/<name>/SKILL.md.

1. Start a fresh Codex TUI session in that workspace.

1. Verify that fresh-session behavior is correct:

• $ shows the usual system skills
• project-local MCP is available

1. Exit Codex.

1. Resume an older session for the same workspace.

1. Press $ again and compare with the fresh session.

Observed result in the resumed session:

• the $ skill picker can be empty
• project-local context is not equivalent to a fresh session in the same workspace

What is the expected behavior?

A resumed session should restore the same effective workspace-derived behavior as a fresh session started in that same directory.

That includes:

• the same project-local MCP availability
• the same system/project skill visibility in $
• the same effective config derived from the workspace
• no observable UX difference between fresh session and resumed session for the same project

Additional information

Additional findings from local investigation:

• The workspace itself is valid: a fresh session in the same directory behaves correctly.
• The issue is specific to resume behavior.
• Explicit skill invocation can still work even when the $ picker is empty, which suggests a UI/session-state mismatch rather than "skills do not exist".
• The problem reproduces in a WSL workspace on /mnt/....
• Investigation strongly suggests fresh-session initialization and resumed-session initialization are not restoring the same project-derived runtime state.

Possible root-cause direction:

• resume may be reusing an already-running thread/session state and not fully rebuilding workspace-derived config, skill state, and project-local MCP state the same way fresh startup does.

Privacy note:

• exact repo name, drive letter, terminal brand/version, and subscription tier are intentionally omitted here.