[Bug]: wait_for_user enters an infinite continuation loop with an unreconciled completed background job

[MichaelLi423]

What happened, and what did you expect?

Calling wait_for_user while the Background Job Board contains a completed but unreconciled task can cause the orchestrator to be repeatedly resumed without any new external user message.
Each resumed turn sees the same Background Job Board reminder and calls wait_for_user again. This produced an apparently unbounded loop and consumed roughly 50% of my GPT Pro quota.
I've already experienced two infinite loop calls. Maybe should we slow the new feature development?

Steps to reproduce

1. Start a background task.
2. Let it complete so it appears as completed, unreconciled in the Background Job Board.
3. Have the orchestrator call wait_for_user.
4. Do not send another user message.
5. Observe repeated orchestrator turns and repeated wait_for_user calls.
   Example repeated output:
   未收到新的 Windows、固件或现场证据；继续等待。 wait_for_user [reason=等待 Windows 构建输出、固件协议确认或现场 R1–R7 证据。]
   This was repeated many times without external user input.

oh-my-opencode.json

"provider": {
    "openai": { "whitelist": ["gpt-5.6-sol", "gpt-5.6-terra", "gpt-5.6-luna", "gpt-5.3-codex-spark"] },
    "opencode-go": { "whitelist": ["kimi-k3", "kimi-k2.7-code", "grok-4.5", "glm-5.2", "deepseek-v4-pro", "deepseek-v4-flash", "mimo-v2.5"] }
  },
  "watcher": { "ignore": ["node_modules/**", "dist/**", "target/**", ".git/**"] },
  "permission": {
    "read": "allow",
    "edit": "allow",
    "question": "allow",
    "skill": "allow",
    "todowrite": "allow",
    "glob": "allow",
    "grep": "allow",
    "list": "allow",
    "task": "allow",
    "lsp": "allow",
    "webfetch": "allow",
    "websearch": "allow",
    "bash": "allow"
  },
  "agent": { "explore": { "disable": true }, "general": { "disable": true }, "plan": { "disable": true } },
  "lsp": true

OpenCode version

1.18.5

oh-my-opencode-slim version

2.2.8

Operating system

MacOS 26.5.1

Logs, screenshots, or extra context

[mhenke]

This was generated by AI during triage.

Quick update on the root cause hunt.

The idle reconciliation path is guarded by hasInputWait, so it can't fire while wait_for_user is active. That rules out the obvious trigger. rearmContinuationForUserMessage only runs on real user messages, role=user with non-synthetic parts, and no code path calls it without actual input.

So what resumes the orchestrator without user input? We don't know yet. Candidates: a foreground fallback race where invalidateContinuation doesn't clear the waiting-for-user state, the model ignoring the stop instruction and looping within one turn, or the continuation evaluator bypassing when continueOnIdle is false.

This reads like the same symptom as #924, the wait_for_user loop with unreconciled background jobs. Three PRs are open that touch this area, #925, #921 and #913, but they adjust reconciliation timing, not the resume trigger itself. I'd rather keep this open until those land and we can verify against this specific repro.

Two questions that would narrow this down:

• What is your continueOnIdle setting?
• Is the loop intra-turn (multiple wait_for_user calls in one model response) or inter-turn (several separate turns)?

[DjakaTechnology]

just got bitten by this too, didnt know there's such thing as wait_for_user tool now (seem just added 2 weeks ago), left a task run over night and it burns entire weekly usage token because of this infinite loop.

Before this tool call added, usually AI will just stop if they need user input, this tool causes the AI to keep calling wait_for_user when they needed user input, and it burns token so much if user is not looking at the AI, which defeats the reliability of the orchestaor it self.

I'm using stock OpenCode and stock OMO Slim config (just disable the floating graphic only)

[mhenke]

This was generated by AI during triage.

Closed as fixed. PRs #925 and #921 landed today and directly address the infinite continuation loop -- #925 fixes the idle-only reconciliation guard, and #921 reconciles injected terminal jobs.