A command pane's background job outlives its command

A dogfood agent's background jobs died when the command that started them
finished, even under nohup. The command's shell leads its terminal's
session, and on its exit the kernel hangs up the terminal's foreground
group, which with job control off is the shell's and every job's. The line
now runs with job control on (bash, sh, dash, zsh, ksh -m; fish status
job-control full), so a job has a group of its own and lives on, printing
below exit N, and survives the pane closing. While a job holds the pty the
pane is not reused, so the directory's next command gets a second pane
(cmdexit's golden, re-recorded by name).

Co-Authored-By: Claude Opus 5.5 <[email protected]>

1 files changed, 9 insertions, 2 deletions

diff --git a/docs/fs.md b/docs/fs.md
index 3800e8cb..a883e185 100644
--- a/docs/fs.md
+++ b/docs/fs.md
@@ -249,12 +249,19 @@ same tree without leaving the process.
   is typed into that shell. From anywhere else -- a file, a scratch, a tag,
   a terminal whose tty a program holds -- it runs as a command pane: a
   terminal whose child is the root ctl's `Shell` (fish unless set) run
-  with `-c` and the line, in the pane's directory,
+  with `-c` and the line, in the pane's directory, with job control on
+  (bash, sh, dash, zsh, ksh `-m`; fish `status job-control full`),
   which shows its output and then `exit N` (its tag reads `<dir> (<line>)
   running`, then `exit N`), and stays. The command is over when its process
   exits, as in acme, not when its terminal closes: a job it left in the
   background prints on below `exit N` until it lets go of the pty, and a
-  command that lets go of its terminal early runs on to its own exit. The directory's next command runs in
+  command that lets go of its terminal early runs on to its own exit. A
+  background job outlives the command: job control gives it a process
+  group of its own, so the hangup the kernel sends the terminal's
+  foreground group when the shell exits misses it. It survives the pane
+  closing or taking the next command too, but its writes to the terminal
+  then fail, so start one that must keep writing with `nohup` or its
+  output redirected. The directory's next command runs in
   that pane once it is done, below what it showed, after a `% <line>` line;
   one still running gets a second pane. Before the next command the pane
   leaves any alternate screen and turns off the modes a program left on