File operations become invalid after entering the conversation via “codex resume xxx” in a non-historical working directory

Resolved 💬 3 comments Opened Oct 28, 2025 by kK-2004 Closed Nov 25, 2025

What version of Codex is running?

v0.50.0

What subscription do you have?

plus

Which model were you using?

gpt-5

What platform is your computer?

wsl on windows11

What issue are you seeing?

In a Windows 11 WSL environment, when I run the command codex resume xxx from the ~ (home) directory to resume a previous session that was originally started inside a directory such as /mnt/d/xxx, all subsequent file operations inside that resumed session become invalid.

Specifically, commands such as file creation, modification, or deletion execute without any visible error messages, and the console output indicates that files were created successfully. However, upon inspection, the corresponding files do not actually appear in the filesystem.

This issue occurs only when resuming a session (via codex resume xxx) from a different working directory (e.g., from ~ instead of the original /mnt/d/xxx). It seems that the resumed environment loses proper access or synchronization with the original WSL-mounted Windows filesystem path, resulting in silent failures of file operations without any exception or warning.

What steps can reproduce the bug?

In Windows 11 WSL, open a terminal and go to the home directory:

cd ~

Run the command to resume a previous session (which was originally in /mnt/d/xxx):

codex resume xxx

Inside the resumed session, request Codex to add a new feature (e.g., feat) — this should, in theory, generate a new Java file.

The terminal output shows a message indicating that the file has been successfully created.

However, when checking the directory, the expected Java file does not actually exist.

What is the expected behavior?

_No response_

Additional information

If you then switch to the original working directory where the session was created and run the same command again:

cd /mnt/d/xxx
codex resume xxx

the file generation works correctly, and the Java file appears as expected.

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗