---
name: omp-background-job-deadline-debug
description: "Diagnose a background bash job/service killed mid-run (\"Command timed out after Ns\") in omp: find which deadline owned it (tools.maxTimeout cap vs async default), prove it from the bundle, and launch long jobs uncapped as ready-log services."
---

# Omp background-job deadline forensics

Symptom: an async `bats`/build job dies with `[Command timed out after 300s|600s]`
while the same launch once ran 18+ min ("no deadline").

## Cause map (proven against the pinned bundle)
Resolver in `dist/cli.js`: `let v=n??300, R=v===0, k=R?void 0:ep("bash",v,x)` where
`qx.bash={default:300,min:1,max:3600}` and `x` = config key `tools.maxTimeout`
("Maximum timeout in seconds the agent can set for any tool", default 0).
- Request absent → `qx.bash.default` 300 s.
- Request > 0 → clamped by `tools.maxTimeout` when set (e.g. 600 caps a 1800 request).
- Request 0 → meant "no deadline", but `0` sometimes arrives as missing (falsy drop
  upstream of the resolver) → silently 300 s. Filed as tool issue; treat any
  async job over ~5 min as untrustworthy.

## Diagnose in three moves
1. `grep -o 'qx={bash:{[^}]*}' <omp bundle>` — policy table (`command -v omp` →
   `readlink -f` → `dist/cli.js`).
2. `read cfg://tools` — live `maxTimeout` (value ≠ 0 explains any hard cap).
3. Compare kill notices: the number in "killed once it has run Ns" is the resolved
   deadline; 300 = default reached (request dropped), other values = your request
   or the config cap.

## Launching jobs longer than the cap
- Named **services are not deadline-capped**: `bash(name:"x", pty:false, command:"…; echo DONE >> log", ready:{log:"DONE", timeout:900})`.
  Readiness fires on the log pattern; result does NOT auto-deliver — `wait` on it or read `proc://x` after the supervisor notice.
- NEVER end the service command with `echo "EXIT $?" >> log` and trust the
  supervisor's exit code — the trailing echo masks it (supervisor reports 0 while
  the log says EXIT 1). The log line is the truth; grep the log for the recorded
  code and `^not ok` before believing any "exit code 0".
- Do not raise `tools.maxTimeout` unasked: session-scoped `write cfg://tools/maxTimeout`
  needs user approval and may be declined — respect it, use the service route.

## Multi-suite hazard
Suites that rebuild shared artifacts per test (e.g. dankvoice bats rebuilds `dist/`)
must not run concurrently — one suite at a time, or per-worktree copies only.