Use ShardStitch with OpenCode.
An OpenCode process can stay active after tool calls finish, or the desktop app can stop at a large Git change set. ShardStitch rebuilds the checkout state and writes a handoff for a fresh OpenCode run or another client.
Integration paths.
.opencode/handover.md.
This is how the next OpenCode session receives the recovered working state.
Auto-configured at ~/.config/opencode/opencode.json under mcp local.
When supported, OpenCode can call ShardStitch locally instead of relying only on pasted context.
Yes - ShardStitch supports recovery for this tool and combines it with verified repo state. Public docs show the outcome, not the private capture method.
Setup path.
Record the last tool call, command result, and any files changed before reopening the desktop view.
Run ShardStitch in the project to write .opencode/handover.md. The local MCP entry is configured in ~/.config/opencode/opencode.json.
Compare the recovered state with Git and rerun the relevant check. Start the next run from one specific pending action, not an assumed completed tool call.
Limits to know.
OpenCode's local session data may help, but a visible spinner does not establish whether a command finished. Treat the saved diff and actual command output as evidence; mark incomplete tool results as pending. Recovery does not fix an upstream provider outage.
Resume this workflow.
Use the OpenCode tool-call hang guide when the CLI stays alive after tool calls. If the desktop app freezes on a Git review, preserve the diff from a terminal before restarting the UI.
Best use case.
Recovering OpenCode work into Claude Code, Codex, or a fresh OpenCode run.
Failure recovery
What fails first.
The CLI can remain alive after all visible tool calls are complete, while the desktop app can freeze loading a large Git change set. Users also report a mid-task model spinner that needs manual interruption. See CLI runs that never exit, desktop Git freezes, and mid-task hangs.
What to preserve before retrying.
How to continue safely.
Capture the local state and provider error, then resume with a focused continuation packet. Start OpenCode again if it is the right tool, or hand the packet to another supported AI coding tool without rebuilding the story by hand.
ShardStitch treats the project as evidence: verified disk facts are kept distinct from inferred claims, so the next agent knows what to trust and what to check first.
Common errors and fixes.
Separate a process-exit issue from a Git loading issue, and verify files outside the old session before retrying.
Run never exits after tool calls
Check the completion reason and stop the process if no new state is appearing. Preserve stdout, diff, and next action. See issue #17516.
Desktop freezes loading Git changes
Reduce repository scope and inspect the working tree from a terminal before reopening the review panel. See issue #29078.
Model loads indefinitely
Interrupt once, record the provider/model and partial changes, then restart with one focused test instead of replaying the full transcript. See OpenCode issue #17516, opened March 14, 2026 for OpenCode v1.2.26, which reports the process staying alive after tool calls complete.
Binary or PATH failure
If the command is unavailable, record the environment and current git state before reinstalling or changing shell configuration.
Terminal rendering failure
When the interface becomes unreliable, trust the files, diff, and test output rather than the visual state of the TUI.
FAQ.
Can I trust the last OpenCode tool call after the spinner stops?
Check the command output and repository directly. If the result is missing, mark that check as unverified in the handoff and run it again in the new session.
Open the researched failure guide, preserve the work that reached disk, and continue from a clean verified state.
More OpenCode recovery guides.
Use the desktop startup freeze guide for a stuck UI and the mid-task Escape guide for a run that may still be active.