Run and manage long-running background processes.

Use `start` only for processes that must keep running independently after this tool call returns, such as development servers, file watchers, local services, and test watchers (`npm run dev`, `next dev`, `vite`, or `bun --watch`).

`start` returns immediately and never blocks your turn. `monitor` starts the same kind of process but waits for its output, bounded by a line cap and a wall-time cap, so you read progress instead of polling. Do not start `sleep`, timers, cooldowns, delays, or polling loops with this tool. Outside a session goal, wait a fixed time with a blocking shell command and raise its `timeout`. In a session goal, a time-based wait must use `schedule_wakeup` or `cron_create` so the goal suspends; a blocking shell sleep is progress and the goal loop will spin.

Do not use the shell tool with `&`, `nohup`, `disown`, `setsid`, `Start-Process`, or similar backgrounding patterns. Processes started with this tool are tracked and shown in the CLI sidebar.

Actions:
- `start`: start a new background process. Include `command`, optional `workdir`, optional `description`, optional `ready` detection, and at most one lifetime option.
- `monitor`: run `command` and return its output as it arrives. Accepts optional `workdir`, `description`, `ready`, `lines`, and `timeout`; the process has session lifetime.
- `list`: list background processes for this session.
- `status`: inspect one process by `id`.
- `logs`: return the retained tail output for one process.
- `stop`: terminate one process and its child process tree.
- `restart`: stop and restart one process with its original command and lifetime.

Monitor:
- `lines` caps how many output lines are returned (default 200, clamped to 1..1000).
- `timeout` caps wall time in milliseconds (default 120000, clamped to 5000..600000).
- `monitor` also stops as soon as the process exits. Reaching either cap does not stop the process: it keeps running as a normal background process, and the result names the process `id` so you can follow up with `logs`, `status`, or `stop`.
- Prefer `monitor` over `start` plus repeated `logs` when you need the output of a command that finishes on its own, such as a build, a test run, or a deploy. Use `start` for servers and watchers that should outlive the call.

Goals:
- In a session goal, `monitor` blocks the goal turn until the process stops, so the goal does not spin while the process runs; the process exit resumes the goal.
- A non-terminal `start` suspends the goal until the process exits, and the exit resumes the goal.
- Do not explore the repository, search for a deploy, or poll with bash when the goal is to wait for a deploy, build, or CI job; schedule that wait. Do not report blocked because no deploy is visible.

Lifetime options for `start`:
- By default, the process stops when its session ends, the user switches session groups, or Kilo exits.
- Set `inherit: true` only from a subagent when the process should transfer to the immediate parent session after the subagent ends. It then follows the parent session lifetime.
- Set `persistent: true` when the process must survive both session closure and Kilo shutdown. Persistent processes are visible and manageable from every session, including after Kilo starts again.
- `inherit` and `persistent` cannot be combined.

Only include `id` for `status`, `logs`, `stop`, and `restart`. Do not invent or pass an `id` when starting or monitoring a process.

Readiness:
- Use `ready.pattern` when the process prints a recognizable line like `ready`, `Local:`, or `started server`.
- Use `ready.port` when a local server should accept TCP connections on a known port.
- If readiness is not known, omit `ready`; the process is returned as running immediately.
