Codex confidently misstates integration capabilities by conflating CLI-agent support with VS Code extension control

Open 💬 1 comment Opened Aug 2, 2026 by luxueliu

What issue are you seeing?

The user repeatedly asked whether a third-party agent IDE could control the coding agents already installed as VS Code extensions. The purpose was specifically to avoid installing and juggling multiple standalone terminal CLIs.

Codex researched documentation that described support for CLI agents, but answered as if that proved the IDE could directly control the existing VS Code extensions and their sessions. Based on that confirmation, the user installed the IDE.

After installation, Codex reversed its answer and instructed the user to install separate standalone CLIs. A targeted local check then showed the actual capability split:

one VS Code extension bundled a reusable CLI core;
another extension exposed only a VS Code extension entrypoint and no independently launchable CLI;
the IDE could launch CLI processes, but could not take over the VS Code extension panels or their existing sessions.

Expected behavior

Before recommending installation, Codex should explicitly distinguish:

direct control of a VS Code extension UI/session;
reuse of a CLI core bundled inside an extension;
installation of a separate standalone CLI;
launching that CLI inside an integrated terminal.

Documentation that says "supports any CLI agent" is not evidence that a product controls VS Code extensions. If that exact boundary is unverified, Codex should say so instead of confidently confirming compatibility.

Environment:

OpenAI Codex Desktop 26.727.6591.0 (x64 MSIX)
Windows 10.0.26200.8875
Model observed: GPT-5.6 Sol

No private workspace files or transcripts are attached.

View original on GitHub ↗

1 Comment

luxueliu · 26 days ago

Exact measured incident impact

This symptom occurred within the same August 1–2 incident documented in #34477 and #36555. The figures below describe shared incident severity; they are not all attributed exclusively to this one symptom.

Local rollout reconstruction, using each rollout's final payload.info.total_token_usage.total_tokens and the root/child parent_thread_id graph, produced:

Initial task family: 11 sessions, 420,775,426 tokens
Reopened task family: 5 sessions, 61,684,846 tokens
Recovery/harness task families: 76,001,530 tokens
Original incident total: 558,461,802 tokens
Later failed reattempt: 25,544,534 tokens
Cumulative affected/recovery total: 584,006,336 tokens
User-visible loss during the original incident: approximately 80% of the weekly allowance (about 60% in the first run and another 20% after reopening)
At least one no-progress segment ran for approximately 35 minutes before manual interruption
Original implementation outcome: zero planned features completed

Private project transcripts are not attached. Redacted event counts and relevant log-field samples can be supplied if maintainers request them.