What should I do if Esc does not stop OpenCode?

Press Esc twice and wait briefly. If the prompt does not return, stop the process from another terminal, reopen the repository, and inspect git status and git diff.

Why is OpenCode stuck at compaction or Preparing write?

Both states have issue reports. Verify the last tool call and target files before continuing because the visible stall does not establish what reached disk.

Can I resume an interrupted OpenCode task?

Yes. Preserve the last tool call, changed files, command output, verification state, and next action, then resume in OpenCode or another supported tool.

OpenCode stops after a tool call or keeps hanging? The file write may already be complete.

Q: Why does OpenCode stop after a tool call?

OpenCode can remain blocked after a tool call even when the underlying read, command, or file write completed. Inspect the repository before replaying the action.

Q: How do I get OpenCode out of Plan mode?

Switch to the Build primary agent with Tab or the configured agent-switch keybind. If the mode remains stuck, begin a fresh Build session with a verified continuation packet.

A reported OpenCode failure leaves opencode run alive after a read or write tool finishes successfully. The CLI never exits, but the project change may already be on disk.

Quick answer: inspect the final tool output, git status, git diff, and file timestamps before killing or replaying the process. If the write completed, continue from the resulting files instead of asking another agent to repeat it.

OpenCode looks frozen, but files are still changing.

Source checked 12 September 2026: OpenCode issue #46559, opened 1 September, reports this symptom on OpenCode 1.18.25 in Windows Terminal on Windows 11. The activity animation continued without visible progress; after the reporter interrupted the agent, previously hidden activity and file edits appeared. The issue was open when checked. We have not independently reproduced it or verified a fix. This is distinct from a completed opencode run process failing to exit.

Inspect before retrying.

In a second terminal, open the same repository and run these inspection commands. They do not reset, stage, or discard your work:

git --no-optional-locks status --short --untracked-files=all
git --no-pager diff --no-ext-diff --no-textconv
git --no-pager diff --cached --no-ext-diff --no-textconv

Git status lists staged, unstaged and non-ignored untracked paths; Git diff shows unstaged changes, while --cached shows staged changes. Open untracked files separately: their contents do not appear in these diffs. Inspect the target file directly if it is ignored or the project does not use Git.

Content keeps changing: do not send the same edit again or launch another writing agent. Compare the actual target-file contents and tool output after a short observation interval. Existing changes may belong to you or another process; a diff alone does not identify their author.
No new changes: this does not prove a deadlock. The tool may be reading, waiting on a provider, running a command, or awaiting input. Inspect the last tool call and any visible permission or input prompt.
You need to stop: use the normal interrupt for your interface, then confirm the active tool and any child command have stopped. If you cannot confirm this, keep the state marked uncertain and do not start a second writer.
Before resuming: preserve the stopped project's changed and untracked files, record the last tool output, and inspect the final diff. Run the relevant project check, then request only the next unfinished action.

Limits: a timestamp is a clue, not proof of a complete write. These reads are not an atomic snapshot while a process is writing. A clean diff does not prove external actions succeeded. Do not delete session data, run a destructive reset, or repeat a deployment or database operation just because the interface looks stuck. Redact secrets before sharing diagnostics.

What the failure looks like.

The tool reports a successful read or write and then produces no final response or exit code. In automation, the parent process keeps waiting even though the useful filesystem work has finished.

If OpenCode will not exit.

In the TUI, press Esc twice and allow the active tool call time to settle. For a non-interactive opencode run process, stop that process from another terminal after confirming its file operation completed. Reopen the repository and inspect git status and git diff before sending another request.

OpenCode stuck at compaction.

OpenCode uses a hidden system agent to compact long context automatically. An open issue reports that processing can stop immediately after compaction and require a manual continuation. Before sending continue, inspect the repository and note the last completed tool call. Send one bounded continuation only after you know what reached disk.

Compaction boundary: a compacted summary can carry intent, but it does not prove that the last edit, command, or check finished. Verify those facts from the repository.

OpenCode stuck on Preparing write.

The exact Preparing write... stall is tracked in the OpenCode issue repository. Treat it as an uncertain write, not a failed write. Check the target file, its diff, and timestamp from another terminal. If no content changed, restart with a smaller single-file edit. If the write landed, continue from that file and do not replay it.

OpenCode stuck in Plan mode.

OpenCode documents Plan as a restricted primary agent and Build as the agent with normal file and command access. Use Tab, or your configured switch_agent keybind, to select Build before asking for implementation. If the UI still reports Plan after the switch, start a fresh session explicitly in Build and carry over the verified packet. Do not work around Plan restrictions with shell commands or an unrestricted subagent.

Why the CLI may not exit.

The open issue documents a completion-detection failure after tool use: the model finishes its read and write operations, but the process does not terminate. The issue is still open, so treat process termination and file completion as separate facts.

Fix it without losing the task.

Stop the failing request or loop before it creates more unknown changes.

Inspect git status, git diff, changed files, and the last known-good check.

Record the failed attempt and the constraint that made it fail.

Restart with one bounded action and an explicit verification step.

What the next AI should receive.

The last tool call, file changes, command output, process action, and next verification step.

Immediate recovery

Confirm whether the final read or write completed, stop only the hanging process, then resume from the verified files with one explicit check.

What survives

The last tool call, file changes, command output, process action, and next verification step.

Trust boundary

A previous AI claim is a claim to check. The repository and test output are the evidence.

How ShardStitch helps.

ShardStitch scans local project state and builds a continuation packet for the same tool or another one. It keeps verified disk facts separate from inferred claims, so the next session can see what changed, what failed, what remains unknown, and what to check next. OpenCode is supported. The packet lets a fresh CLI or another tool verify what actually reached disk.

Source trail.

FAQ.

Why does OpenCode stop after a tool call?

An open issue reports that opencode run can finish its tool calls but fail to exit. Verify the completed filesystem work before retrying.

Why is OpenCode stuck at compaction?

An open issue reports that processing can stop after automatic compaction. Verify the last tool result, then send one bounded continuation or move the verified state to a fresh session.

What should I do when OpenCode says Preparing write?

Check whether the target file changed before stopping or retrying. A stalled status does not establish whether the write reached disk.

How do I get OpenCode out of Plan mode?

Switch to the Build primary agent with Tab or your configured agent-switch keybind. If the UI remains stuck, start a fresh Build session and carry over a verified handoff.

What if the old session is already gone?

Recover the current goal, changed files, git state, decisions, failed approaches, verification status, and next action from the project and available local artifacts.

Can the work move to another AI tool?

Yes, when the project state is available locally. The continuation packet carries useful state into a fresh session or another supported tool.

Scope note: This page describes a reported failure pattern and a practical recovery path. Behavior changes with versions, providers, operating systems, and repository size.