Codex Desktop review pane empty for WSL workspace because Git watcher uses Windows-local paths
Resolved 💬 5 comments Opened Apr 22, 2026 by eschulma Closed Apr 30, 2026
💡 Likely answer: A maintainer (github-actions[bot], contributor)
responded on this thread — see the highlighted reply below.
What version of the Codex App are you using (From “About Codex” dialog)?
26.421.11020
What subscription do you have?
Pro $200
What platform is your computer?
Microsoft Windows NT 10.0.22631.0 x64
What issue are you seeing?
Summary
Codex Desktop correctly detects unstaged file count for a WSL workspace, but the Review pane renders empty. Logs show Git commands run against the WSL path, while the Git repo watcher runs as a Windows-local watcher and calls fs.watch on raw Linux paths like /home/.../.git.
WORKAROUND: Creating a Windows symlink from C:\home\... to the WSL UNC path works around the issue, which strongly suggests a WSL path translation bug.
Environment
- OS: Windows with WSL Ubuntu
- Workspace path in WSL:
/home/ekane/src/github.com/sentrylink/webapp - Codex Desktop package:
OpenAI.Codex_26.421.620.0_x64__2p2nqsd0c76g0 - App server version from logs:
0.123.0-alpha.5 - Session host reported in logs:
hostId=local,isRemote=false
What steps can reproduce the bug?
Symptoms
- Open a Git repo stored under WSL, for example:
/home/ekane/src/github.com/sentrylink/webapp
- Modify several files.
- Open the Review pane.
- The header correctly reports unstaged files, e.g.
3 files changed. - The Review pane body is empty.
What is the expected behavior?
Unstaged files should be shown with their diffs in the Review pane.
Additional information
Relevant Logs
Git commands are issued with the WSL cwd:
cwd=/home/ekane/src/github.com/sentrylink/webapp
hostId=local
isRemote=false
5 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
I think this has the same underlying cause as #17991 but is a separate symptom.
I'm hitting this as well, I was prompted to mention this id:
019dc710-fcbb-70e2-b64c-10b01b13aea3@InsightfulFuture note my workaround -- the Windows symlink has worked wonders.
I'm going to close this, if #17991 is fixed this should correct as well. In the meantime my Windows symlinks are doing the job.