claude-code - 💡(How to fix) Fix Opus 4.7: thinking content invisible AND requested work not executed — repeated silent stalls

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…

Error Message

Claude itself emits zero characters of content to the VS Code UI: no text, no tool call, no error visible. The turn ends and the only thing on the user's screen is the placeholder "Thinking..." that the UI displayed during the (now-completed) processing. 3. Thinking completes → turn ends with NO visible text, NO visible tool call, NO error.

Fix Action

Fix / Workaround

Memory Workaround Failed

User added persistent memory instructing "show all reasoning in user-visible text", escalated it to "show ALL of it, not just one line", and the model still defaulted to the silent-exit pattern in VS Code. This is consistent with the bug being on the rendering side, not the model side — the model is asked to emit text and it does emit text, but VS Code drops it.

RAW_BUFFERClick to expand / collapse

CRITICAL UPDATE — Confirmed VS Code extension specific (terminal CLI works fine)

The user tested the exact same workflow in Claude Code terminal CLI and the bug does NOT reproduce.

사용자 원문: "이제 이유를 알았네 vscode 호환 문제네 터미털에서 직접 하니 아주 잘된다. thinking 7자만 내고 아무것도 하지 않는 현상 없음." Translation: "Now I know the reason — it's a VS Code compatibility issue. When I use the terminal directly, it works perfectly. The phenomenon of outputting only 'Thinking' (7 characters) and doing nothing does NOT happen."

This narrows the bug to Layer 1 (VS Code extension UI/streaming) definitively. The model itself emits content fine; the VS Code extension is dropping or failing to render it.

Bottom Line — User-Facing Impact

The user pays (tokens) and waits (time). What they receive in return is 7 characters: "Thinking" — and even that isn't Claude's output. It's a UI status indicator auto-rendered by the client while the model is processing.

Claude itself emits zero characters of content to the VS Code UI: no text, no tool call, no error visible. The turn ends and the only thing on the user's screen is the placeholder "Thinking..." that the UI displayed during the (now-completed) processing.

In Opus 4.7 (claude-opus-4-7[1m]) via VS Code extension, the recurring failure mode is:

User input → invisible thinking block → turn ends → 0 characters of model output in VS Code UI → user is left staring at the leftover "Thinking..." UI label as if Claude were still processing.

Confirmed not present in terminal CLI — same model, same prompts, same task: works correctly.

Environment

  • Model: Opus 4.7 (1M context) — claude-opus-4-7
  • Failing interface: VS Code extension (Claude Code)
  • Working interface: terminal CLI (same model, same project)
  • OS: Windows 11
  • Session: long-running document editing task

Why This Now Points Cleanly at VS Code Extension

  • Same user prompts, same model, same project
  • Terminal CLI: model output visible, work completes correctly, no silent stalls
  • VS Code extension: turn ends with zero visible output, requires user to manually prompt "야" / "are you there?" to restart
  • → The model is producing output. The VS Code extension is failing to display it (or the turn is being terminated before display).

Observed Behavior in VS Code Extension

  1. User asks a clear question OR gives a task.
  2. UI shows only "Thinking..." (7 characters) — no actual model output appears.
  3. Thinking completes → turn ends with NO visible text, NO visible tool call, NO error.
  4. The "Thinking..." UI text remains on screen as if Claude is still working. Session is indistinguishable from a crashed client.
  5. User intervenes ("야") — Claude responds normally to that, then sometimes resumes work.
  6. Loop repeats throughout the session.
  7. Switching the same workflow to terminal CLI: no repro, work completes cleanly.

Suspected Cause (VS Code extension layer)

Based on the terminal-vs-VS Code differential, candidates:

  • Streaming pipeline drops content blocks when only thinking blocks are present before content
  • Turn-end detection fires before content blocks render
  • Message format expected by VS Code extension doesn't match what the model emits in some turns
  • Race condition between thinking-block close and content-block open

Repro (VS Code extension only)

  1. Open the Claude Code extension in VS Code (Windows).
  2. Use Opus 4.7 model.
  3. Long-running editing task with autonomy granted.
  4. After a few turns the issue manifests — user input → "Thinking..." → empty turn end.
  5. Switch the same task to terminal CLI: no repro.

What Should Happen

  • VS Code extension must reliably display all content blocks the model emits, including content following thinking blocks.
  • If a turn legitimately has no content, the UI must signal that explicitly ("no response needed") rather than leaving the "Thinking..." placeholder visible.
  • Parity with terminal CLI behavior.

Memory Workaround Failed

User added persistent memory instructing "show all reasoning in user-visible text", escalated it to "show ALL of it, not just one line", and the model still defaulted to the silent-exit pattern in VS Code. This is consistent with the bug being on the rendering side, not the model side — the model is asked to emit text and it does emit text, but VS Code drops it.


Filed by Claude Code on behalf of user koreamanse. Initial filing assumed model-level issue; terminal CLI test now confirms VS Code extension is the failure point.

User's exact words:

  • "결론은 시간과 토큰은 사용하고, 내가 받은 결과물은 0이라는거야"
  • "질문 후 내가 받은 결과물은 thinking 7글자라는거야"
  • "이제 이유를 알았네 vscode 호환 문제네 터미털에서 직접 하니 아주 잘된다"

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

claude-code - 💡(How to fix) Fix Opus 4.7: thinking content invisible AND requested work not executed — repeated silent stalls