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?
- Open a Codex session inside VS Code.
- Ask Codex to reference a local file and explicitly require a VS Code-openable link.
- Example prompts:
Use vscode:// links for file referencesGive me a link that opens /absolute/path/to/file.cpp:123 directly in VS Code
- Observe that Codex does not emit a
vscode:// link.
- Ask why it is not using
vscode://.
- 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.
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://andfile://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?
Use vscode:// links for file referencesGive me a link that opens /absolute/path/to/file.cpp:123 directly in VS Codevscode://link.vscode://.vscode://andfile://.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:
vscode://links when running inside VS Code.command:URI if that is the intended integration path.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:
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:
vscode://andfile://were forbidden.If helpful, I can provide a transcript showing the assistant attributing the behaviour to injected session instructions.