server: model step hangs with no timeout, session stays busy until interrupted #53747

Summary

A session's model step can stall indefinitely: the provider stream stops producing anything, but the step never times out, errors or retries. The session stays busy with no progress until it's interrupted by hand. Anything left running unattended stops silently, and a parent session waiting on a stalled subagent waits forever.

Environment

• opencode version: 2.0.23
• OS: Linux x86_64
• Terminal: not relevant; sessions run under opencode serve and are driven through the HTTP API
• Shell: not relevant
• Install/channel: latest
• Active plugins: none
• Provider and model where it happened: github-copilot with claude-opus-5.5 (variant high)

Reproduction

It's intermittent, but frequent under steady load:

1. Run opencode serve and start a session on the provider and model above.
2. Give it a long task that delegates to background subagents (the subagent tool with background: true), each making many tool calls.
3. Leave it running unattended for an hour or more.

Expected Behavior

A step whose stream produces nothing for a configurable time gets retried, or fails with an error that the session and its parent can see, the same way provider errors already surface. A parent waiting on a subagent learns that the subagent failed.

Actual Behavior

• The last assistant message stays open: time.completed is unset, and the last part is a reasoning or text part, or a tool part still marked running or streaming although its command finished long before.
• No new step starts, and nothing more is logged for the session.
• It stays that way until POST /api/session/:id/interrupt, which records {"type":"aborted","message":"Step interrupted"}. A follow-up prompt then continues normally.
• Over three days of use: 34 interrupted steps across 18 sessions. Ten had stalled for 20 minutes or more, five for over an hour, and the longest for almost four hours.
• A stalled background subagent leaves its parent session waiting indefinitely.

Additional Context

• Possibly related. On the same provider and model, a few steps failed outright with Session.StepFailedError: Provider blocked the response (reasoning_extraction). Those surface as errors, so they're less harmful than the silent stalls.
• After a server restart. Sessions that had been mid-step kept showing tool parts as running. They didn't resume, and they couldn't be told apart from live work through the API.
• Workaround. An external script polls GET /api/session and GET /api/session/:id/message?limit=1. When a step has made no progress for 25 minutes, it calls /interrupt and then /prompt with a short "continue" message. This works, but it shouldn't be needed.
• Suggestion. Add a per-step inactivity timeout, measured from the last stream event and configurable globally and per provider, that retries once and then fails the step visibly. On startup, mark steps left open by a previous server process as interrupted.