OpenCode stuck after Escape? Verify the process and files.

An interrupted interface does not prove that the command stopped or the edits were lost. Check the process and worktree, preserve the diff, and only then decide whether to restart or retry.

Do this first: Press Escape twice if the surface supports it. If the session remains blocked, restart the process, then compare the diff with the last known-good commit.

What the failure looks like.

The spinner remains active, the conversation stops advancing during a tool sequence, Escape interrupts the task, or OpenCode keeps trying an invalid or unknown tool pattern.

Why it happens.

The session surface can remain active after the underlying tool call or model response has stopped progressing. In a tool loop, the model may keep trying an action the local environment cannot execute, so a fresh bounded request is safer than another broad retry.

Fix it without losing the task.

Record the terminal surface, OpenCode version if known, last visible action, and whether a child command is active.

Press the documented interrupt once and wait for a clear state change. Do not issue a second task while the first process may still be running.

If the UI remains blocked, save the diff and use the deliberate stop or process-termination path appropriate to that surface.

After restart, compare the working tree with the last known-good commit and run one focused check before replaying any tool action.

What the next AI should receive.

Terminal surface, OpenCode version, last action, whether a child process remained active, stop or restart action taken, changed files, current diff, and the next focused verification.

Check before restarting

If Escape appears ineffective, verify whether the OpenCode process or child command is still active. Preserve the diff before using a stop control or terminating a process.

Boundary of the evidence

Issue #1418 is a closed historical report with no listed product version or verified fixed release. Its Escape symptom came from one Zed terminal setup.

Diagnostic checkpoint

An Escape keypress is not proof of process exit; verify the terminal child and repository before retrying.

How ShardStitch helps.

ShardStitch can carry the last action, changed files, and actual verification output into a clean OpenCode session. It cannot confirm that Escape stopped a running command; check the process and repository.

Source trail.

Specific report, checked September 24, 2026: OpenCode issue #1418 was opened July 30, 2025 and is now closed. A user running OpenCode in a Zed terminal reported it stuck on “working” and double-Escape failing to exit. The issue lists no product version and does not identify a verified release containing a fix. See the OpenCode documentation; treat the report as historical and terminal-specific, not proof of a current general defect.

FAQ.

Does pressing Escape twice always stop an OpenCode task?

No. The behavior depends on the current surface and active command. Verify a stop signal or process exit before assuming the action ended.

Is issue #1418 evidence of a current OpenCode defect?

It is a historical Zed-terminal report without a listed version or confirmed fixed release. Check current behavior in your own version and terminal.

Scope note: Evidence boundary: the linked Escape report is historical and terminal-specific. Use it as one example, not proof that current OpenCode sessions generally ignore Escape.