You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
opencode:rescue hangs in worktrees when run_in_background is used #16
When opencode:opencode-rescue is dispatched with isolation: "worktree" and the rescue subagent runs its single Bash call with run_in_background: true, the subagent returns immediately. Claude Code sees the subagent exit with no file changes and deletes the worktree — but OpenCode is still running inside the now-deleted directory and hangs indefinitely.
Two paths reach this state today:
Explicit: the user includes --background in the rescue request. plugins/opencode/skills/opencode-runtime/SKILL.md:26 and plugins/opencode/agents/opencode-rescue.md:23 treat --background as "Claude-side execution control" without explicitly forbidding run_in_background: true on the Bash call.
Implicit: for long prompts, Claude Code sometimes decides to background a slow Bash call on its own.
Suggested fix
Update plugins/opencode/skills/opencode-runtime/SKILL.md and plugins/opencode/agents/opencode-rescue.md to say: strip --background before calling task, and do not set run_in_background on the Bash call. The rescue subagent must wait for OpenCode to complete, because backgrounding in a worktree causes silent orphaning.
Rescue uses opencode-companion task --background for the long-running path already (see handleTask in opencode-companion.mjs:325-342), which spawns a detached worker. That mechanism is the correct way to background OpenCode, not run_in_background on Bash.
Activity
JohnnyVicious commentedon Apr 12, 2026
Consolidated into #17. The run_in_background worktree hang should be fixed as part of the rescue forwarding contract/backgrounding redesign.
fix(rescue): inline forwarding into the slash command (closes #17)
fix(rescue): inline forwarding into the slash command (closes #17) (#58)