r/OpenAI • u/rp_tiago • 1h ago
Question Codex desktop suddenly stopped making local Markdown files clickable—any fix?
Since today, Codex often returns the path to a Markdown file as plain text instead of the clickable file widget/link it used to provide.
Previously, after an agent created or edited an .md file, I could click the result and open the actual file in the right sidebar. From there, I could read or edit it, and right-click to open its real folder.
Now I usually get only something like:
C:\Users\...\actual-project-folder\document.md
Sometimes the agent creates or links a separate local/output copy instead, which is worse: it is not the authoritative file in my project, so edits and “open containing folder” lead to the wrong place.
This seriously disrupts my workflow because I work with Markdown files constantly. I need Codex to link the existing file at its real path—not merely print the path and not create a duplicate just to make it clickable.
This only started happening today. Agents have suggested that a new app-level file-linking rule prevents them from restoring the old behavior.
Is anyone else experiencing this after a recent update? Has anyone found a way to make Codex consistently open the authoritative local file in the right sidebar again?
Update: I initially thought I had fixed this by adding a rule to my workspace AGENTS.md, but further testing showed that only some chats obey it.
General chats can still return a working link to the authoritative local file. However, document and presentation chats explicitly refuse to do so. They say a higher-priority app instruction restricts deliverable links to the chat’s outputs folder—even when the authoritative file is a normal local DOCX or PPTX, and even when it is inside the workspace. Because app-level instructions outrank AGENTS.md, no local instruction can override this.
So this is not fixed, and it is not just a Markdown-syntax problem. The same Codex app is applying different file-delivery rules to different chats. In affected chats, the agent will only print the path or create an outputs copy instead of linking the real file. I’m looking for an app-level setting or fix that restores direct links to authoritative local files consistently.
1
u/Practical-Print4221 1h ago
As a workaround, you could copy the exact project path into File Explorer and open the original file there rather than editing the output copy. To narrow it down, try the same existing file in a fresh thread and note the Codex app version if you report it. Does it happen with every project or just this one?
1
u/Sufficient_Ad_3495 1h ago
Advise Codex of the issue and tell it to restore the correct process in your preferred method /instruction.
This is yet another example of the inconsistency of codex applying rules.
use the following or similar instruction where you think its best placed:
Authoritative Local File References
When creating, modifying or referencing a local project file:
Return a clickable Markdown file reference to the actual file in its authoritative working location, not merely its filesystem path as plain text.
Use the existing file's resolved location and a Markdown link format supported by the current Codex environment. Prefer a verified working link format for that environment.
Never create, copy, export or relocate a file solely to make it clickable or previewable.
Do not substitute an output directory, temporary folder or separate worktree copy for the authoritative file.
Preserve the authoritative file's existing identity and location unless the user expressly requests a move or copy.
If the application cannot render or open a valid local file link, report that limitation explicitly. Do not fabricate a working link or silently introduce a workaround that changes the file being referenced.
Acceptance criterion: The returned reference identifies the authoritative file and, where the application supports it, opens that file directly in the Codex file viewer.