Skip to content

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

Closed
Closed
File viewer sends /C:/... paths and fails with AbsolutePathBuf deserialized without a base path#32474
Labels
appIssues related to the Codex desktop appapp-serverIssues involving app server protocol or interfacesbugSomething isn't workingremotewindows-osIssues related to Codex on Windows systems

Description

@onerbaris
onerbaris
opened on Jul 11, 2026

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

Activity

  1. onerbaris
    added
    appIssues related to the Codex desktop app
    on Jul 11, 2026
  2. github-actions
    added
    bugSomething isn't working
    windows-osIssues related to Codex on Windows systems
    app-serverIssues involving app server protocol or interfaces
    remote
    on Jul 11, 2026

  3. github-actions commented on Jul 11, 2026

    @github-actions
    github-actionsBot
    on Jul 11, 2026 – with GitHub Actions
    Contributor

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

    Powered by Codex Action

  4. Oct-2300 commented on Jul 21, 2026

    @Oct-2300
    Oct-2300
    on Jul 21, 2026 – with ChatGPT Codex Connector

    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.

  5. logohere commented on Aug 4, 2026

    @logohere
    logohere
    on Aug 4, 2026

    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.

  6. onerbaris
    closed this as completedon Sep 24, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    appIssues related to the Codex desktop appapp-serverIssues involving app server protocol or interfacesbugSomething isn't workingremotewindows-osIssues related to Codex on Windows systems

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions