›_ Codex Issues
Codex Issues / #17591

Windows desktop app copies local file links as app:// URLs instead of usable filesystem paths

Resolved 💬 3 comments Opened Apr 13, 2026 by Bortlesboat Closed Apr 13, 2026
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Summary

On Windows in the Codex desktop app, local file or image references in assistant messages often render as blue clickable links, but copying those links does not copy a usable filesystem path. Instead, the clipboard gets an internal app URL such as:

app://-/index.html?hostId=local

That makes it hard to locate files Codex says it created or edited.

Environment

  • Platform: Windows desktop app
  • User workflow: copying local file/image links from Codex responses
  • Related issue: #17548 covers a different but adjacent file-link/path rendering problem on macOS

Steps to reproduce

  1. Ask Codex to create or edit a local file or image in the desktop app.
  2. Let Codex respond with a blue clickable local link or file reference.
  3. Copy that link from the response.
  4. Paste it into a text field or editor.

Actual behavior

The pasted value is an internal app URL like:

app://-/index.html?hostId=local

rather than the real Windows path to the file.

Expected behavior

Users should be able to reliably get the actual local path, for example:

C:/Users/name/.../file.png

At minimum, the app should provide a clear way to copy the underlying filesystem path instead of the internal app URL.

Why this matters

This is a real usability problem, especially for less technical users. Codex may say it created an image or wrote a file, but the user still cannot easily find it. The current behavior makes local artifacts feel invisible unless the assistant separately prints the raw path in plain text.

Suggested fixes

  1. Add a Copy path action for local file/image references.
  2. Show the raw filesystem path in the UI alongside the clickable link.
  3. Ensure copying a local file reference can yield the actual path instead of app://-/index.html?hostId=local.
  4. Consider having desktop responses display the raw path by default for local outputs.

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 4 months ago

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

  • #16228
  • #16148
  • #16234

Powered by Codex Action

Bortlesboat · 4 months ago

A more concrete real-world example from actual usage on Windows:

I ask Codex to create something local, for example:

  • an image
  • a markdown file
  • an output artifact from a script

Codex then responds in a way that implies the file is available "here" via a blue link. But from the user side, that often does not solve the problem at all.

What happens in practice:

  • I see a blue link in the Codex desktop app.
  • I try to copy it so I can open the file myself.
  • What I get is not the real path, but an internal app URL like app://-/index.html?hostId=local.
  • So I still do not know where the file actually is on disk.

This is especially bad for images. Codex may effectively say "I made this picture, here it is," but the UI does not make it easy to answer the user's next obvious question: "where is that file on my computer?"

The result is that local outputs feel invisible unless the assistant separately prints the raw Windows path in plain text.

From a UX perspective, this is painful for users who are not very comfortable navigating deep folder structures manually. The current experience creates a mismatch between:

  • what the assistant implies (the file is available and easy to access)
  • what the app actually enables (the user still cannot reliably get the real filesystem path)

A few improvements that would help a lot:

  • a visible raw path under local file/image outputs
  • a right-click or button action for Copy path
  • a clearer distinction between internal app links and actual filesystem locations

Without that, local files are technically created, but practically hard to retrieve.

Bortlesboat · 4 months ago

Proposed product solution:

The desktop app should support local artifacts as first-class file objects, not just styled links.

Recommended behavior for any local file/image output:

  • Open should open the file directly in the OS default app, or reveal it in Explorer/Finder if that is safer.
  • Copy path should copy the real filesystem path.
  • The raw path should also be visible in plain text so users can confirm where the file lives.

In other words, the correct fix is not just "make the link prettier." The app should make local outputs genuinely usable.

Suggested UI pattern:

  • filename
  • full local path in plain text
  • actions: Open Reveal in folder Copy path

Why this matters:

  • Users expect "here is the file" to mean they can actually open it.
  • This removes the confusion between internal app URLs and real files.
  • It especially helps with generated images and other outputs where the next question is naturally "where did you save it?"

If only one thing gets implemented first, my vote would be:

  • make Open open the actual local file
  • make Copy path copy the actual local path

That would solve the core usability problem immediately.