Feature: run_in_background flag for bash + completion notifications #24885

Problem

The bash tool blocks the assistant turn until the command exits or hits the
2-minute default timeout. For long-running commands the model wants to launch
and revisit later — dev servers, watch processes, builds, log followers — this
forces awkward workarounds (& + redirects, nohup, polling) that the model
handles inconsistently and tends to get wrong.

Claude Code addresses this with a run_in_background: true flag on its bash
tool plus a completion-notification mechanism. Opencode currently has no
equivalent, and it shows up as a routine friction point.

Why it belongs in OpenCode

This is a parity gap with a battle-tested pattern, not a net-new product
surface. Models are already trained to use run_in_background in CC, so
adding it here means existing model behavior just works. It also unblocks
a class of workflows (long-running watchers, soak tests, dev servers) that
are currently painful.

Proposed approach

High-level shape:

• Add an optional run_in_background: boolean parameter to the bash tool.
  When true, the spawn returns immediately with a task ID + output file
  path; the command runs detached, with output streamed to a file in
  opencode's existing truncation directory.
• Add a bash_kill (or generic task_stop) tool that takes a task ID and
  terminates the running task. Reading partial/final output uses the
  existing Read tool against the output file path — no new "bash_output"
  tool needed.
• On natural completion or stall-detection, attach a synthetic part to the
  next user message handed to the LLM, telling the model the task ended
  (status, exit code, output file path). This reuses opencode's existing
  insertReminders / synthetic-text-part convention rather than introducing
  a new attachment vocabulary.
• A one-shot stall watchdog detects commands blocked on stdin (heuristic on
  the output tail) and emits a notification with a kill+rerun-with-piped-input
  recovery instruction.

Internally: a BackgroundTask service forks workers into the instance scope
(so they survive the bash tool returning), publishes Bus events on lifecycle
transitions, and a notifier subscribes to those events and queues per-session
notifications. Drain happens at the same loop seam as insertReminders.

I have a working branch implementing this; happy to share details or open a
draft PR if the design is approved in principle.

Open questions for maintainers

I'd particularly value direction on these before opening a PR:

1. Naming / scope. Is this strictly a bash feature (BashTasks service,
   bash_kill tool), or is there appetite for a more generic background-task
   framework now (BackgroundTask service, task_stop tool with bash being
   the first kind)? Affects future extensibility.
2. Notification envelope. CC wraps the completion notification in a
   <task-notification> XML structure; my current draft uses opencode's
   <system-reminder> envelope for consistency with insertReminders.
   Match CC's format for closer behavioral alignment, or keep the opencode
   convention?
3. Feature flag. Should this ship behind an experimental flag (e.g.
   OPENCODE_EXPERIMENTAL_BASH_BACKGROUND) until it has real-world soak time?
4. Kill-after-completion semantics. CC throws "not running" if you try to
   kill a finished task; I made it a no-op returning the existing status.
   Either is defensible — preference?

Not in scope (deferred from CC parity)

Calling these out so it's clear what's not being proposed for v1:

• Auto-backgrounding of long-blocking commands (CC moves them to background
  after ~15s in assistant mode)
• Mid-flight backgrounding (CC's Ctrl+B equivalent)
• Per-agent notification routing (would scope by sessionID for now)
• TUI-side fold of consecutive completion notifications
• Notification priority levels

Each could be a follow-up if there's demand.

Status

Working branch is ready locally. Will open a PR referencing this issue once
the design questions above have direction.