Diagnosing a frozen Cline panel

01. Know where the logs live

Devin (a VS Code fork) keeps logs and extension storage under its own app-name folder, using the same layout as stock VS Code.

~/Library/Application Support/Devin/logs/<session-id>/
    main.log                          … the app as a whole
    window1/exthost/exthost.log       … extension host log (per window)
    window1/exthost/output_logging_*/1-Cline.log … Cline output panel log
    ptyhost.log, terminal.log         … terminal layer

~/Library/Application Support/Devin/User/globalStorage/saoudrizwan.claude-dev/
    tasks/<task-id>/ui_messages.json          … every message shown in the UI
    tasks/<task-id>/api_conversation_history.json … model exchanges (per API request)

For stock VS Code, replace Devin with Code. Other forks follow the same structure — just look for the app name under ~/Library/Application Support/.

02. Find "what happened last" in the task history

Locate the most recently modified task ID under tasks/ and read the tail of ui_messages.json.

ls -lat ~/Library/Application\ Support/Devin/User/globalStorage/saoudrizwan.claude-dev/tasks | head

python3 -c "
import json, datetime
with open('.../ui_messages.json') as f:
    data = json.load(f)
for m in data[-10:]:
    ts = m.get('ts')
    t = datetime.datetime.fromtimestamp(ts/1000) if ts else None
    print(t, m.get('type'), m.get('say') or m.get('ask'), str(m.get('text',''))[:200])
"

Pay attention to the type of the last message before the freeze.

• ask: resume_task … the classic case: the task session was cut off and is waiting to be resumed.
• say: command with nothing after it … a command was sent but no result came back.
• stuck at say: api_req_started … the model request itself never returned.

03. Confirm whether the command actually finished

The UI may look frozen while the command has in fact completed underneath. Don't judge from logs alone — check the real artifacts.

• Inspect the timestamps and contents of files or logs the command touched (e.g. /tmp/xxx.log).
• Check whether the process it was starting is actually alive with ps aux | grep <name>.
• Verify the binary it was installing really exists via which or ls.

04. Common causes

Multi-line commands containing # comments

Interactive zsh does not treat # as a comment by default (setopt interactive_comments is off). When AI-generated commands include lines like # explanation, you get errors such as zsh: parse error near ')', and terminal integration can be left in a bad state.

Fix: add setopt interactive_comments to ~/.zshrc.

Races from pasting long multi-line commands at once

The timing of streaming in the command string can race with the shell becoming ready, duplicating leading characters (echo → eecho). That garbling breaks shell integration's command-boundary detection, leaving the session waiting for completion forever.

Fix: add custom instructions (e.g. in .clinerules) telling the agent to split work into short commands with few lines each.

05. Recovery steps

1. Once you know the command really finished, try "Resume Task" first.
2. If the button itself is unresponsive, Cline's webview is likely frozen. Close the panel and reopen it.
3. Still stuck? Cmd+Shift+P → Developer: Reload Window. Task history lives on disk (globalStorage/tasks/), so nothing is lost.
4. After the reload, reopen the task from "RECENT", close the broken terminal tab, then press "Resume Task".
5. Once back, tell the model directly that "X is already done" to skip pointless re-runs and polling.

06. Preventing a repeat

• Add setopt interactive_comments to ~/.zshrc.
• Put a .clinerules at the project root that explicitly says: don't send large multi-line commands at once, split them into short ones.