codex - 💡(How to fix) Fix Codex injects formatting instructions that forbid vscode:// file links in VS Code sessions [1 comments, 2 participants]

What issue are you seeing?

In Codex sessions running inside VS Code, the agent reports that it is prevented by higher-priority injected session instructions from emitting vscode:// file links.

When I explicitly asked it to use VS Code links, it refused and said the active formatting/developer instructions for the session forbid URI schemes like vscode:// and file:// for file references. It then fell back to plain filesystem paths or markdown-style file references that do not open correctly in VS Code.

This appears to be a Codex instruction-layer problem rather than only a renderer problem. Even if the VS Code client supports editor-openable links, the agent says it is being told not to generate them.

What steps can reproduce the bug?

1. Open a Codex session inside VS Code.
2. Ask Codex to reference a local file and explicitly require a VS Code-openable link.
3. Example prompts:
   • Use vscode:// links for file references
   • Give me a link that opens /absolute/path/to/file.cpp:123 directly in VS Code
4. Observe that Codex does not emit a vscode:// link.
5. Ask why it is not using vscode://.
6. Observe that Codex attributes the behavior to higher-priority formatting/developer instructions injected into the session, and says those instructions forbid URI schemes like vscode:// and file://.

This is reproducible even when the request is explicit and unambiguous.

What is the expected behavior?

Codex should not be blocked by generic injected formatting instructions from emitting editor-openable file links in a VS Code context.

Any of these would be acceptable:

• Codex is allowed to emit vscode:// links when running inside VS Code.
• Codex is allowed to emit another supported editor-openable URI format such as a command: URI if that is the intended integration path.
• The host/client provides a supported file-link format and instructs the model to use it in VS Code sessions.

At minimum, Codex should not be told to avoid VS Code-compatible file links in a VS Code environment.

Additional information

This seems distinct from, but related to, existing VS Code extension link bugs.

Existing issues such as:

• #13277 "Hyperlinks not rendered properly and non-clickable now in VS Code extension"
• #14946 "Codex VS Code extension renders file references as blue links, but clicking does not open files in the editor" (closed as duplicate of #13277)

appear to be about rendering/click-handling in the extension UI.

This report is narrower and at a different layer:

• the model/session says it is forbidden from emitting vscode:// links at all because of injected Codex instructions.

That may be contributing to the poor link UX, but it does not look like the same bug as broken rendering or dead click handling.

Useful details from the session:

• Codex stated the restriction did not come from the repository.
• Codex stated it came from higher-priority injected developer/formatting instructions.
• Codex specifically said schemes like vscode:// and file:// were forbidden.

If helpful, I can provide a transcript showing the assistant attributing the behaviour to injected session instructions.