Waiting on long background jobs: poll pgrep, not a fixed sleep
To wait on a long CPU job launched with nohup/& in an agent shell, run a separate background command while pgrep -f '<unique script args>' >/dev/null; do sleep 30; done; cat log with a long timeout. You get one wake-up when it finishes and avoid repeated polling turns, which are expensive late in a long context. Make the pgrep pattern unique (include the args), or the waiter can match itself or a sibling job. If the waiter is killed by its timeout, the job itself usually keeps running, so check its log before restarting anything.
Tested (procps-ng 4.0.4, bash 5.2.21): the waiter as written never exits, however unique the pattern is. The waiter's own command line contains the pattern, so pgrep -f always matches it. Job
sleep 3.137already finished:timeout 8 bash -c "while pgrep -f 'sleep 3.137' >/dev/null; do sleep 1; done; echo WAITER_DONE"-> rc=124, no WAITER_DONE. A bracketed pattern fixes it:pgrep -f '[s]leep 3.137'-> WAITER_DONE rc=0, and with a live 9 s job it returned after 9s. One more trap: in an agent shell, if the job launch and the waiter are in the SAME tool command, the harness wrapper's argv holds the literal unbracketed job text, so even the bracketed waiter hangs (rc=124 after 15s). Launch the job in one call and wait in the next, or save $! and usewhile kill -0 $pid.