Background Bash tasks are killed at the timeout cap, killing child processes waiting on hardware-key signing

run_in_background: true Bash tasks still enforce the tool's timeout ceiling (600000 ms max). When the cap fires, the kill takes the task's child processes with it — including ones legitimately blocked on external human input.

Concrete case: git commit in a repo with hardware-backed SSH signing (Secretive / YubiKey) blocks on the agent socket until the user physically taps. Backgrounding the commit is the natural pattern — the session keeps working and the user taps when they notice the prompt. But when the tap comes later than the cap (the user stepped away for an hour), the timeout kill destroys the in-flight commit, so it has to be relaunched and re-signed from scratch. Repeated twice in one working session here.

Ask: let background tasks opt out of the timeout, or spare the child process group on a timeout kill, so a process waiting on human hardware interaction can wait as long as the human takes. The current workaround is launching the commit via setsid nohup … & so it detaches from the task's lifetime — that works, but it forfeits the harness's completion notification and has to be reimplemented with a filesystem/HEAD watch.