›_ Codex Issues
Codex Issues / #32474

File viewer sends /C:/... paths and fails with AbsolutePathBuf deserialized without a base path

Open 💬 3 comments Opened Jul 11, 2026 by onerbaris
💡 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.707.41301

What subscription do you have?

Pro

What platform is your computer?

Darwin 25.5.0 arm64 arm

What issue are you seeing?

When the macOS ChatGPT/Codex desktop app connects to a native Windows host through the built-in "Connect other devices" feature, the project directory and filenames are visible, but opening any file fails with:

Could not open file

The same files open normally when ChatGPT/Codex is used directly on the Windows host.

The macOS logs show that a valid Windows path such as:

C:\Projects\RemotePathTest\README.md

is sent in the fs/watch request as:

/C:/Projects/RemotePathTest/README.md

The Windows app-server then returns:

Invalid request: AbsolutePathBuf deserialized without a base path

The remote client can successfully list the directory and display its filenames. The failure occurs when it attempts to open the selected file.

This appears to be a client-side cross-platform path normalization issue. A Windows drive path is being converted into a POSIX-shaped /C:/... path before it is sent to the Windows app-server.

What steps can reproduce the bug?

  1. Install and run ChatGPT/Codex Desktop on a native Windows machine.
  2. Pair the Windows machine through the built-in "Connect other devices" feature.
  3. From ChatGPT/Codex Desktop on macOS, connect to the Windows host.
  4. Open a Windows project such as:
C:\Projects\RemotePathTest
  1. Create a file:
C:\Projects\RemotePathTest\README.md
  1. Confirm that the macOS remote client can list the project directory and see README.md.
  2. Click README.md in the macOS remote client.
  3. Observe Could not open file.
  4. Inspect the macOS logs and observe an fs/watch request containing:
/C:/Projects/RemotePathTest/README.md
  1. Observe the following error:
Invalid request: AbsolutePathBuf deserialized without a base path
  1. Open the same file directly in ChatGPT/Codex on the Windows host.
  2. Observe that it opens normally.

What is the expected behavior?

When the macOS client is connected to a native Windows host, Windows drive paths should remain valid Windows paths when sent to the Windows app-server.

For example:

C:\Projects\RemotePathTest\README.md

should not be converted into:

/C:/Projects/RemotePathTest/README.md

Clicking a file that is visible in the remote project browser should load and display its contents in the macOS client.

Additional information

_No response_

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 1 month ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #32108

Powered by Codex Action

Oct-2300 · 1 month ago

This is also reproducible with a Windows desktop client talking to its native local Windows host; it is not limited to a macOS client connected to Windows.

Environment

  • Microsoft Store ChatGPT/Codex app: 26.715.8383.0
  • Embedded frontend: 26.715.61943
  • Windows 11 x64
  • Native local Windows workspace (not WSL)

Opening a local generated/output Markdown file caused the valid drive path to be sent to fs/watch in POSIX-shaped form:

/C:/.../file.md

The app-server rejected it with the same error:

Invalid request: AbsolutePathBuf deserialized without a base path

The same behavior occurred historically with an ordinary local PowerShell file, so Unicode filenames, Markdown content, and file size are not required triggers.

On this build the failure can cascade into the uncloseable Markdown file-tab issue in #33160: the file editor installs an async onBeforeClose guard, the load/save path fails, and a stale guard can keep returning false. The right DetailPanel then remains mounted and continues generating ResizeObserver/layout churn.

Suggested boundary fix:

  • When and only when the destination host is native local Windows, normalize /^\/[A-Za-z]:[\\/]/ by removing the leading slash and using native separators before all read/open/write/watch RPCs.
  • Do not apply that transform to POSIX remote hosts, WSL/container paths, or UNC paths.
  • Make file-tab close and watcher disposal independent of whether fs/watch successfully registered.

Raw local paths and full logs are intentionally omitted; targeted sanitized log excerpts can be provided privately.

logohere · 23 days ago

Current-build confirmation: native local Windows still sends /C:/... to fs/watch

This remains reproducible on the current Windows desktop package and does not require macOS remote control, WSL, or a cross-device host.

Environment

  • Windows 11 Pro: 10.0.26200
  • Microsoft Store package: OpenAI.Codex 26.727.6591.0
  • Internal desktop release: 26.727.51351
  • Native local Windows workspace

Observed behavior

On a clean desktop relaunch, the app attempted to watch a local Markdown file using a POSIX-shaped drive path of the form:

/C:/Users/<redacted>/projects/<redacted>/docs/<redacted>.md

The app-server rejected the request with:

Invalid request: AbsolutePathBuf deserialized without a base path

The desktop log then recorded:

Failed to watch open file

Across the three most recent startup logs sampled after the relaunch, there were:

  • 2 occurrences of AbsolutePathBuf deserialized without a base path
  • 1 occurrence of Failed to watch open file

The correct native path begins with C:\, not /C:/.

Isolation

This persisted after:

  • fully terminating all ChatGPT.exe processes;
  • clearing only rebuildable Chromium/GPU caches;
  • resolving unrelated Git safe.directory ownership errors for restored worktrees.

That makes this a separate path-normalization/file-watch defect rather than a cache or Git ownership failure.

No raw local paths, file contents, credentials, or conversation data are included.