task-work silently writes no TAB_ID when the tab lookup misses, so 'no tab id captured' surfaces hours later in task-done #242

Symptom

task-done prints:

Skipping zellij close-tab (no tab id captured; close this tab manually if needed).

and the tab does not close. Reported on both kiro and claude, intermittently.

Cause: the capture fails silently at a different time, in a different command

claude-gh/bin/task-work:295-298 (and the six sibling copies, region info-tab-id):

INFO_TAB_ID=$(aw_zellij_tab_id_by_name "$SLUG" || true)
if [[ -n "$INFO_TAB_ID" ]]; then
  printf 'TAB_ID=%s\n' "$INFO_TAB_ID" >> "$INFO_FILE"
fi

When the lookup returns empty, no TAB_ID= line is written and nothing is printed. The block is not guarded on $ZELLIJ either — it runs unconditionally and fails quietly.

So task-work succeeds, the worker runs for hours, and the first sign anything went wrong is task-done's message at teardown — by which time the context that caused it is gone. The user cannot act on the message because it reports a consequence in the wrong command.

This is the same failure shape the repo has now fixed three times: #194 (an empty check list reads as green), #182 (a filter that never executed and failed open), #229 (two distinct failures that both wrote no log line). A state that is invisible because its failure mode produces no artifact.

Evidence

Auditing every <worktree-base>/.<slug>.info on this machine — 9 of 36 sidecars across 8 repos have no TAB_ID, and they are not randomly distributed:

gdi-chatbot-worktrees:
  .add-readme.info                                                TAB_ID=[]
  .add-readme-7qegu.info  .add-readme-9wgw1.info                  TAB_ID=[]
  .add-readme-g8sgw.info  .add-readme-ldwpy.info                  TAB_ID=[]
  .add-readme-smy9q.info                                          TAB_ID=[]
  .bug-model-renders-table-but-the-chat-already-outpu.info        TAB_ID=[]
  .bug-model-renders-table-but-the-chat-already-outpu-hu1s5.info  TAB_ID=[]
  .fix-stores-skill.info                                          TAB_ID=[]

every other repo (retail-scraper, recommender-systems, groppo, portai, task-force): TAB_ID populated

Two shapes stand out, both produced by task-work itself:

• Collision suffixes. task-work:206-207 appends a random 5-char hash on a name collision (SLUG="${SLUG}-${HASH}"). Six add-readme variants exist, so that path ran repeatedly.
• 50-char truncation. task-work:136 does SLUG="${SLUG:0:50}". bug-model-renders-table-but-the-chat-already-outpu is exactly 50 characters.

Both are cases where the name task-work asks zellij for is one it derived through a transformation — which is where a mismatch between the slug and the actual tab name would live. Not proven; see below.

What the lookup can return empty for

lib/zellij-tab.sh:38-52, aw_zellij_tab_id_by_name, ends in | .[0] // empty, so empty means no tab matched the name. Four ways to get there:

1. $ZELLIJ unset — task-work run outside zellij, so no tab was created at all. The block does not check for this.
2. no jq on PATH — :42 returns empty.
3. the tab's name is not byte-equal to $SLUG after paint-stripping. Note the paint set (⏸️ /▶️ /❓︎ ) matches radio's exactly, so the documented race the comment addresses is genuinely covered — this would be a different mismatch, e.g. a long name zellij renders differently.
4. a genuine race despite (3).

I could not determine which of these fires from artifacts alone. The distribution above points at (3) and the two transformations that produce it, but the failing tabs are long gone and the message carries no diagnostic.

Fix

Two parts, and the first matters more than the second:

1. Make the failure loud, at the point it happens. When the lookup comes back empty, task-work should say so and say why it can tell — zellij absent, jq absent, or a name lookup that found nothing — and name the slug it searched for. Log it too, so the reconstruction is a grep rather than an audit of every sidecar on the machine. Whatever the trigger turns out to be, this is what makes the next report diagnosable in one line instead of this.

2. Then find the trigger, with (1) in place to report it. Worth checking specifically whether zellij's list-tabs --json .name is byte-equal to the requested name for a 50-char slug, and whether anything in the collision-suffix path creates the tab under a different name than it writes to the sidecar.

Do not fall back to the unscoped zellij action close-tab in task-done — #107/#108 established that closes whichever tab is focused, and task-done:201 already explains why that is worse than skipping.

Verification

• With the lookup forced to return empty, task-work reports it (message + log line) and still completes — a failed tab-id capture must not abort a worker launch.
• The message distinguishes the causes it can distinguish: no zellij, no jq, no match for <slug>.
• A successful capture is byte-unchanged in output (regression guard).
• task-done's existing "no tab id captured" message gains a pointer to the task-work log line, so the two ends of the failure are linkable.
• All seven loadouts: this lives in the drift-guarded info-tab-id region, so the fix lands in every copy or the guard fails.

References

• task-done tab leak: TAB_ID gets clobbered when radio re-registers on session re-init (--auto / non-auto regression, broader than #109) #117 — why TAB_ID is persisted in $INFO_FILE at all, and the paint-race the current comment addresses
• task-done close-tab leaks to focused tab — closes PM tab when user switches away mid-cleanup #107 / task-done close-tab leaks to focused tab: scope close-tab to the worker's TAB_ID (#107) #108 — why task-done must not fall back to unscoped close-tab
• tab + .info handling: stale TAB_ID can close an unrelated tab, an ambiguous tab name can resolve wrong, and .info is parsed by sourcing it #180 — the stale TAB_ID case (tab not closed, or wrong tab closed); this is the absent case, same observable
• task-done's unregister is undone one turn later: a failed close-tab leaves the agent alive and its next hook re-seeds the session #241 — the surviving agent re-seeds the session its task-done wiped, which is what makes a failed close look like a failed unregister