claude-code - 💡(How to fix) Fix VSCode extension: /goal preview text fills the chat panel and pushes assistant responses out of view until user types

Environment

• Claude Code CLI: 2.1.140
• VSCode: 1.121.0 (commit f6cfa2ea2403534de03f069bdf160d06451ed282) on Linux x64
• Interface: Claude Code VSCode extension (running inside VSCode native extension chat panel)
• Goal feature: /goal slash command (session-scoped Stop hook)

Symptom

When I fire /goal <long multi-paragraph prompt> in the Claude Code VSCode extension chat, the goal-preview block (a copy of the full goal text rendered into the conversation scrollback) appears to take over the entire visible chat area. Subsequent assistant responses appear in the conversation but are pushed out of the visible viewport, so it looks like Claude has gone silent.

The state persists until I type ANY character into the input box, at which point the chat re-renders and the assistant's responses become visible above the goal block.

Repro

1. Open Claude Code chat in the VSCode extension
2. Fire /goal with a multi-paragraph body (mine was ~30 lines of markdown — a phase brief with tables, bullets, and a few sections)
3. Wait for the assistant to acknowledge the goal and start working
4. Observe: visible chat area still shows the goal-preview block; assistant's "Goal acknowledged" + any subsequent tool calls/text are not visible
5. Type one character into the input box → chat re-renders and assistant responses become visible above

Expected

After firing /goal, the assistant's acknowledgement + ongoing turn should be visible in the chat scrollback the same way any normal assistant response would be. The goal preview should not occupy the full viewport.

Impact

• For autonomous goal flows where the user walks away after firing /goal, the user thinks Claude is unresponsive when they return — they don't see any work happening
• For interactive goal flows, the user has to type a throwaway character to "unstick" the viewport every time they fire a goal

Workaround

Type any character in the input box → forces a re-render → assistant responses become visible.

Notes

Filed on behalf of the affected user. Reported during a long-running multi-phase orchestration session where this pattern recurred every time /goal was fired with a non-trivial goal body.

Thanks!