titah run --bg --auto "work through the migration"
# bg_a490a57d ses_acac583a-…
titah bg list
titah bg logs bg_a490a57d -f # stops on its own when the turn ends
titah bg stop bg_a490a57d # kills the whole tree, sub-agents included--bg detaches the turn and returns immediately, printing the background id and
the session it runs in. The session is an ordinary one: resume it in the TUI
with /session, or read it back with titah sessions list.
!!! warning “Detached turns cannot answer a dialog”
With no client attached, anything needing a permission dialog is
auto-denied. A background turn that will touch files needs --auto or an
explicit permission.allowlist, or it will spend its whole run being
refused. See Permissions & undo.
There is no stored status
bg list asks the operating system whether the process is alive, every time
it is read. Nothing is cached.
A background process can finish at any moment, and nothing is around to tidy up
after it — so a saved status column goes stale with nobody there to notice. A
list that confidently reports “running” for something that died an hour ago is
worse than no list.
Output goes to a file, not a pipe
A pipe dies with its parent. Work that ran and left no readable trace is the exact opposite of why anyone detaches something in the first place, so the output is written to a file that outlives the shell that started it.
bg logs -f follows that file and stops on its own when the turn ends,
rather than hanging until you press Ctrl+C and wonder whether it finished.
bg stop kills the tree
stop kills the whole process group — sub-agents, background shells started by
bash_start, everything the turn spawned. Killing only the parent leaves
children holding ports and writing files, which is the failure mode that makes
people stop trusting a stop button.