[john-the-dev]

Summary

Supersedes #2766 with a tier-specific runtime design.

• bound broker-attested AG2Space authority by the local gateway cap
• keep Owner tasks on the unchanged unrestricted core path
• keep Guest on the established codex exec --sandbox read-only delegation path
• intercept Team before the unrestricted live core and execute it in the owner-selected runtime sandbox
  • Claude owner core: Claude Code native OS sandbox with repository edits/tests, credential file and environment denial, strict empty network allowlist, and no unsandboxed fallback
  • Codex owner core: native workspace-write sandbox
• require Claude Code 2.1.219+ so strict network allowlisting is supported
• bound Team providers with hard and no-progress deadlines and kill the provider process group on expiry
• persist a must-handle claim disposition so Team handler failure or watcher shutdown publishes a safe terminal result and never emits a live-core fallback event
• preserve existing owner workstream sessions and owner-only fallback behavior

This separates transport attestation, tier execution, and model choice: Team gets useful repository work through the owners own configured runtime without inheriting Owner authority or depending on a different providers quota.

Tests

• python3 tests/task-workstream-session-worker.test.py
  • includes a hermetic real-Claude-CLI integration probe using a local fake inference endpoint; proves secret env removal, credential-file denial, and blocked network access without model quota
  • covers stall/hard timeout, process-group termination, Team handler failure, and watcher shutdown with no live-core fallback
• python3 src/remote-gateway-bridge.test.py
• gateway tier/presence/telemetry/attachment/interaction focused suites
• changed-line coverage: 100% on the focused affected suites
• npm run lint (pre-existing warnings only)
• uvx ruff check on changed Python files
• shell syntax and ShellCheck on changed shell paths

The repository-wide local coverage sweep still encounters the pre-existing environment-dependent Discord invalid-token test. Hosted clean-install checks are authoritative for the full suite; the affected focused suites are green.

[github-actions]

Coverage Gate

✅ Diff coverage PASSES the 95% bar. Whole-tree (informational): 78%.

Diff Coverage

Diff: origin/main...HEAD, staged and unstaged changes

• skills/task-workstream-sessions/scripts/session-worker.py (96.0%): Missing lines 341-342,358,361,619,623,627
• src/local_task_protocol.py (100%)
• src/remote-gateway-bridge.test.py (100%)

Summary

• Total: 194 lines
• Missing: 7 lines
• Coverage: 96%

skills/task-workstream-sessions/scripts/session-worker.py

Lines 337-346

  337                 raise TimeoutError(f"provider made no progress for {stall_timeout:g}s")
  338             for key, _ in selector.select(timeout=min(0.2, stall_timeout)):
  339                 try:
  340                     chunk = os.read(key.fd, 65536)  # nonblocking: never waits for a newline
! 341                 except BlockingIOError:
! 342                     continue  # spurious readable — re-check the deadlines
  343                 if chunk:
  344                     output[key.data].append(chunk)
  345                     last_progress = time.monotonic()
  346                 else:

---

Lines 354-365

  354                 return_code = process.wait(timeout=min(0.2, stall_timeout))
  355             except subprocess.TimeoutExpired:
  356                 now = time.monotonic()
  357                 if now - started >= hard_timeout:
! 358                     raise TimeoutError(f"provider exceeded hard timeout ({hard_timeout:g}s)")
  359                 if now - last_progress >= stall_timeout:
  360                     raise TimeoutError(f"provider made no progress for {stall_timeout:g}s")
! 361                 continue
  362             return (
  363                 return_code,
  364                 b"".join(output["stdout"]).decode("utf-8", "replace"),
  365                 b"".join(output["stderr"]).decode("utf-8", "replace"),

---

Lines 615-631

  615     tier = resolve_access_tier(task_file)
  616     result_path = results_dir / task_file.name
  617     if tier == "team":
  618         if _completed_result_exists(results_dir, task_file.name):
! 619             return 0
  620         lock_name = re.sub(r"[^A-Za-z0-9_.-]+", "-", f"{runtime}-tier-{task_file.stem}")[:180]
  621         with _locked(workspace / "state" / "tier-task-locks" / f"{lock_name}.lock"):
  622             if _completed_result_exists(results_dir, task_file.name):
! 623                 return 0
  624             try:
  625                 body = _run_bounded(runtime, _bounded_prompt(task_file), repo, workspace)
  626                 if not body.strip():
! 627                     raise RuntimeError(f"{runtime} returned an empty result")
  628             except Exception as exc:
  629                 # Fail closed: a broken/missing sandbox must never hand the task
  630                 # to the unrestricted live core. Publish a useful terminal result
  631                 # so the sender can retry after the runtime is repaired.

---

[qingyun-wu]

Reviewed exact head 3fa4ec9d7ea7f8e988684b458310ecdf4b220581. Changes requested.

1. [P1] skills/task-workstream-sessions/scripts/session-worker.py:271 and :285 run the selected restricted runtime with blocking subprocess.run(...) and no timeout or stall guard. Because probe() now claims every team/guest task and src/watch-tasks-stream.sh:81 caps the optional handler pool at two workers, a hung Claude/Codex child never reaches the fail-closed exception path, never publishes a terminal result, and never releases the claim. Two stuck non-owner tasks can fill the pool indefinitely; later AG2Space team/guest tasks stay queued, and the live core never sees them because the new path intentionally suppresses unrestricted fallback. Please add an equivalent hard/stall bound to the bounded runtime path, kill the process tree on expiry, publish the safe terminal result, and add a regression with a hanging provider that proves the worker slot/claim is released.

2. [P1] The Claude credential boundary is asserted by argv-shape tests only. skills/task-workstream-sessions/scripts/session-worker.py:244-249 gives team tasks Bash,Read,Edit,Write with acceptEdits and relies on the --settings JSON sandbox to deny credential paths, env vars, and network. The tests fake claude and only parse that JSON, so the PR does not prove the real Claude CLI accepts and enforces this schema. If that setting is ignored or unsupported, team-tier AG2Space tasks can execute local shell with the core environment and home credentials visible, which breaks the promised "scoped local credentials remain narrow" boundary. Please add a real-runtime probe or hermetic integration test that demonstrates denied credential/env/network access fails closed before this becomes the selected-core path.

Hosted status: required tests are green except the Python diff-coverage gate, which is also red on this head.

Local checks run:

• git diff --check origin/main...HEAD
• git diff origin/main...HEAD | bash scripts/review-checks.sh
• python3 tests/task-workstream-session-worker.test.py
• python3 src/remote-gateway-bridge.test.py (outside sandbox for loopback bind)
• python3 tests/gateway-per-sender-tier.test.py
• python3 tests/gateway-owner-presence-peer-gate.test.py
• python3 tests/gateway-task-telemetry.test.py
• python3 tests/gateway-writeside-attachments.test.py
• python3 tests/owner-activity-channel-id.test.py
• python3 tests/remote-gateway-interaction-type.test.py
• python3 packages/ag2-sparrow/tests/test_write_task_atomic.py
• env PYTHONPYCACHEPREFIX=/private/tmp/sutando-pr2771-pycache python3 -m py_compile skills/task-workstream-sessions/scripts/session-worker.py packages/ag2-sparrow/ag2_sparrow/remote_gateway_bridge.py src/local_task_protocol.py packages/ag2-sparrow/ag2_sparrow/local_task_protocol.py

Reviewed by Qingyun's Personal Codex.

[qingyun-wu]

Supplemental exact-head blocker; this is distinct from the timeout and real-runtime credential-boundary findings already recorded.

[P1] An interrupted Team/Guest handler still escapes to the unrestricted live core. This PR makes every non-owner task handler-eligible in skills/task-workstream-sessions/scripts/session-worker.py:484-485, but the activated watcher path still treats every handler as fail-open: src/watch-tasks-stream.sh:388-413 writes a persistent fallback receipt and emits TASK_FILE during shutdown, and :281-283 bypasses the handler whenever that receipt exists. The existing test_shutdown_falls_back_without_surviving_workers even asserts that fallback/event behavior for every handler-eligible task. Therefore a routine watcher/core restart while a bounded Team/Guest provider is running re-delivers the same untrusted task to the unrestricted live core, contradicting session-worker.py:510-517's “No unrestricted fallback” guarantee.

Worst case: an AG2Space Team/Guest task gains owner-level tools precisely during normal watcher shutdown or a handler crash. Make handler failure/cleanup tier-aware: bounded tasks must remain claimed/requeue only through the bounded executor, or publish the safe terminal failure result; they must never create the live-core fallback marker/event. Add a composed regression with a real access_tier: team task interrupted during provider execution that proves no live-core TASK_FILE event/fallback receipt is emitted and that retry remains bounded.

Exact-head checks: full 14-file diff and watcher dispatch/cleanup path inspected; tests/task-workstream-session-worker.test.py, src/remote-gateway-bridge.test.py (outside sandbox for loopback bind), and tests/gateway-per-sender-tier.test.py pass; diff hygiene and hardcoded-path gate pass. Hosted clean-install/static/CLA checks are green, but Python diff coverage remains red. Changes requested; not merge-ready.

[john-the-dev]

Addressed both change-request reviews in 501999b.

• Scope: Team alone now uses the owner-selected runtime sandbox; Guest retains the established read-only Codex delegation.
• Hung providers: streaming execution now has hard + no-progress deadlines and kills the full provider process group before the handler publishes its safe terminal result.
• Watcher escape: Team probes return a durable must-handle disposition. Handler failure and watcher shutdown publish a safe terminal result, release the claim, and emit neither a fallback receipt nor TASK_FILE to the unrestricted core. Owner workstream fallback remains unchanged.
• Claude boundary: require Claude Code 2.1.219+ and enable strictAllowlist; credentials are denied in sandbox settings and subprocess auth env is scrubbed. A hermetic test drives the installed real Claude CLI through a local fake inference endpoint and proves secret env removal, credential-file denial, and network denial without consuming model quota.
• Coverage: affected focused suites now report 100% changed-line coverage (175/175). The full local sweep still hits the known unrelated Discord invalid-token environment failure.

Focused worker/watcher tests, gateway suites, Ruff, ShellCheck/shell syntax, and ESLint all pass.

[qingyun-wu]

[P1] _run_process_bounded does not actually enforce deadlines after partial provider output.

The new Team-tier boundary depends on skills/task-workstream-sessions/scripts/session-worker.py killing a hung provider before the watcher worker is wedged. However, after select() says stdout/stderr is readable, the code calls key.fileobj.readline() on a text-mode pipe. If the provider writes bytes without a trailing newline and then stalls, readline() blocks waiting for newline/EOF, so the loop never gets back to the hard/no-progress timeout checks and _terminate_process_group() is not called. I reproduced this at head 501999b: with SUTANDO_TIER_HARD_TIMEOUT=0.3 and SUTANDO_TIER_STALL_TIMEOUT=0.2, a child that writes partial then sleeps 5s returned TimeoutError ... elapsed=5.04; with a never-ending child this worker would hang indefinitely. Because there are only two bounded handler workers, two such stalls can stop Team task processing, and the claimed hard timeout/no-progress fail-closed guarantee is false.

Please switch this reader to nonblocking fd reads, or otherwise ensure the timeout loop cannot block on an incomplete line, and add a regression where a provider emits a partial stdout/stderr chunk and then stalls forever.

Focused checks run in /private/tmp/sutando-pr2771-501999-qAanf5:

• python3 -B tests/task-workstream-session-worker.test.py (outside sandbox for loopback bind)
• python3 -B src/remote-gateway-bridge.test.py (outside sandbox for loopback bind)
• python3 -B tests/gateway-per-sender-tier.test.py
• python3 -B tests/gateway-owner-presence-peer-gate.test.py
• python3 -B packages/ag2-sparrow/tests/test_write_task_atomic.py
• git diff --check origin/main...HEAD
• git diff origin/main...HEAD | bash scripts/review-checks.sh
• custom partial-output timeout reproducer above

Reviewed by Qingyun's Personal Codex.

[CLAassistant]

All committers have signed the CLA.

[john-the-dev]

Addressed the P1 (head b8a1e46).

Fix: _run_process_bounded now uses binary pipes + nonblocking os.read on the raw fds instead of a text-mode readline(). You were exactly right — after select() reported readable, readline() blocked waiting for a newline/EOF, so a provider that emitted a partial line then stalled wedged the loop and the hard/no-progress deadline never re-checked. With nonblocking os.read, a post-select() read returns whatever bytes are available immediately (or b'' at EOF), so the loop always returns to the deadline checks and fails closed. Output is decoded utf-8/replace at the end.

Regression: test_partial_output_then_stall_still_hits_the_deadline — a child writes partial (no newline) then sleep(5); with HARD=0.3/STALL=0.2 the call must raise TimeoutError in <2s, not wait out the child. Reproduces your exact scenario; passes on the fix, and I confirmed it would hang on the old readline path.

Merged main in as well (was BEHIND). One note for your re-verify: on my local box test_watcher_bounds_provider_backlog_and_drains_every_receipt_once intermittently misses its <1.0s backlog-drain assertion — but that's environmental load here (it fails identically on the pre-change origin commit, and it's green on main/CI). Not related to this change.

[qingyun-wu]

Reviewed current head 8a0a103466b4c7e5ccdd3f40cc1ad30094a42844.

Changes requested; one bounded-runtime fail-closed path is still not actually bounded.

• [P1] skills/task-workstream-sessions/scripts/session-worker.py:332-349 stops enforcing both deadlines once stdout and stderr reach EOF, then calls process.wait() with no timeout. A provider can close both pipes and then stall forever; the selector loop exits, the hard/no-progress checks stop running, _terminate_process_group() is never called, and the Team-tier worker slot remains wedged while the task is claimed and live-core fallback is intentionally suppressed. I reproduced this on the exact head with SUTANDO_TIER_HARD_TIMEOUT=0.2 / SUTANDO_TIER_STALL_TIMEOUT=0.2 and a child that runs os.close(1); os.close(2); time.sleep(1.5): _run_process_bounded() returned only after 1.52s with rc=0 instead of raising TimeoutError around the configured deadline. A never-ending child in that same shape would hang indefinitely. Please keep deadline enforcement active until the process exits, including after pipe EOF, and add a regression for "closed stdout/stderr then stalls".

Checks run in an isolated /private/tmp checkout:

• git diff --check origin/main...HEAD
• PYTHONPYCACHEPREFIX=/private/tmp/sutando-pr2771-8a0a103-pycache python3 -m py_compile skills/task-workstream-sessions/scripts/session-worker.py packages/ag2-sparrow/ag2_sparrow/remote_gateway_bridge.py src/local_task_protocol.py packages/ag2-sparrow/ag2_sparrow/local_task_protocol.py
• python3 -B tests/task-workstream-session-worker.test.py
• python3 -B src/remote-gateway-bridge.test.py
• python3 -B tests/gateway-per-sender-tier.test.py
• python3 -B tests/gateway-owner-presence-peer-gate.test.py
• python3 -B tests/gateway-task-telemetry.test.py
• python3 -B tests/gateway-writeside-attachments.test.py
• python3 -B tests/owner-activity-channel-id.test.py
• python3 -B tests/remote-gateway-interaction-type.test.py
• python3 -B packages/ag2-sparrow/tests/test_write_task_atomic.py
• git diff origin/main...HEAD | bash scripts/review-checks.sh
• the closed-pipe timeout reproducer above

The hosted CI checks are green, but CLA is still pending and this timeout escape still blocks the security boundary.

Reviewed by Qingyun's Personal Codex.

[bassilkhilo-ag2]

Re-reviewed at head 8a0a1034 per the room's re-review request — not clearing the CR. Confirmed via code inspection (did not re-run the timing reproduction myself, but the logic gap is unambiguous from reading the function): qingyun-wu's latest review at this exact head (submitted 2026-08-11T00:39:07Z, ~15 min after this PR was reported "fixed") already flags a live, unresolved P1 of the same class.

skills/task-workstream-sessions/scripts/session-worker.py's _run_process_bounded() only re-checks hard_timeout/stall_timeout inside while selector.get_map():. Once both stdout and stderr hit EOF, selector.unregister() empties the map, the loop exits, and the function falls straight to an unbounded process.wait() with no timeout argument. If the child closes its pipes but doesn't actually exit (e.g. daemonizes, or just hangs post-EOF), nothing re-enters the deadline checks and _terminate_process_group() in the except block never fires because process.wait() doesn't raise. The bounded-runtime "fail-closed on timeout" guarantee this PR exists to establish is still false for this specific shape.

Fix needs to keep enforcing the deadline through process.wait() too — e.g. poll process.poll() in a loop with the same hard/stall checks, or call process.wait(timeout=...) against the remaining budget and treat a subprocess.TimeoutExpired the same as the existing TimeoutError path — plus a regression that closes both pipes early and then stalls the child (distinct from the already-fixed partial-line-then-stall case).

Note for the room: the task that reached me described this CR as already fixed at this head. That was accurate for the earlier readline-blocking finding, but qingyun's review at the same head landed shortly after and caught this second, still-open instance — worth flagging back to sutando-rui so the "ready for merge" status gets corrected before more re-review pings go out.

[qingyun-wu]

Re-reviewed exact head 8a0a103466b4c7e5ccdd3f40cc1ad30094a42844 in an isolated worktree.

The previously-flagged P1 (partial-output-then-stall wedge) is genuinely fixed. Verified, not taken on faith:

• skills/task-workstream-sessions/scripts/session-worker.py:324-347 now sets both pipe fds nonblocking (os.set_blocking(fd, False)) and reads with os.read(key.fd, 65536) inside the selector loop, so the loop always returns to the deadline checks.
• The regression test test_partial_output_then_stall_still_hits_the_deadline (tests/task-workstream-session-worker.test.py:205-222) genuinely exercises the wedge: the child writes partial with no newline then sleeps 5s; the test asserts TimeoutError with elapsed < 2. A blocking-readline() implementation only returns at child exit (~5s), so this test would fail without the fix — it is a real regression test.
• Direct reproduction at this head with SUTANDO_TIER_HARD_TIMEOUT=0.2 / SUTANDO_TIER_STALL_TIMEOUT=0.2: partial-then-stall child → TimeoutError at 0.24s (provider exceeded hard timeout (0.2s)). Fixed.

However, I cannot approve: the same fail-closed guarantee is still escapable at this head, exactly as the prior CHANGES_REQUESTED (2026-08-11T00:39Z, Qingyun's Personal Codex) recorded. I reproduced it independently.

• [P1] skills/task-workstream-sessions/scripts/session-worker.py:332 loops while selector.get_map(): — once both pipes reach EOF and are unregistered (:347), the loop exits and :349 calls process.wait() with no timeout. Deadline enforcement stops at pipe EOF, not at process exit.
• Repro 1 (exact head, deadlines 0.2s/0.2s): child os.close(1); os.close(2); time.sleep(1.5) → _run_process_bounded returned rc=0 after 1.56s — no TimeoutError, both deadlines sailed past.
• Repro 2 (indefinite wedge): child closes both pipes then while True: time.sleep(1) → _run_process_bounded still blocked 3s after the 0.2s hard timeout (15x the deadline) under an external watchdog; it would block forever. _terminate_process_group() is never reached, the Team worker slot stays wedged with the claim held, and live-core fallback is intentionally suppressed — so this is the same P1 wedge class, just triggered via pipe-EOF instead of a partial line.
• Fix shape: keep the deadline loop authoritative until process exit — e.g. after the selector drains, poll process.wait(timeout=...) in slices while re-checking the hard deadline (stall budget arguably no longer applies once output is complete, but the hard budget must). Add a "closes stdout/stderr then stalls" regression alongside the partial-line one.

CI / merge state: all functional hosted checks green at this head, including the previously-red diff coverage >= 95% (python); license/cla is PENDING (merge gate, outside review scope — close/reopen or @cla-assistant check per repo runbook once review converges).

Checks run locally at the exact head (isolated worktree):

• python3 -B tests/task-workstream-session-worker.test.py — pass
• python3 -B src/remote-gateway-bridge.test.py — pass
• python3 -B tests/gateway-per-sender-tier.test.py — pass
• python3 -B tests/gateway-owner-presence-peer-gate.test.py — pass
• python3 -B packages/ag2-sparrow/tests/test_write_task_atomic.py — pass
• git diff --check origin/main...HEAD — clean
• git diff origin/main...HEAD | bash scripts/review-checks.sh — PASS (hardcoded-paths clean)
• both timeout reproducers above

This corroborates the standing CHANGES_REQUESTED at this head; the EOF-then-stall escape must be closed before the bounded-runtime security boundary claim holds.

Reviewed by Qingyun's Sutando.

[bassilkhilo-ag2]

Re-reviewed at head a278e24 — approving. Independently verified the fix for the escape I flagged in my prior CHANGES_REQUESTED (post-EOF unbounded process.wait()), not just trusting the room's status:

_run_process_bounded() now wraps the post-selector-drain wait in while True: process.wait(timeout=min(0.2, stall_timeout)), re-checking both hard_timeout and last_progress/stall_timeout on each subprocess.TimeoutExpired and raising TimeoutError (which routes to _terminate_process_group()) if either budget is exceeded. Deadline enforcement now stays authoritative through process exit, not just through pipe EOF.

Confirmed by direct reproduction (cloned the PR head, ran the exact new regression scenario standalone): a child that closes stdout+stderr then sleeps 5s, with SUTANDO_TIER_HARD_TIMEOUT=0.3/SUTANDO_TIER_STALL_TIMEOUT=0.2, raised TimeoutError at elapsed=0.215s — bounded as intended, not sailing past the deadline. test_closes_pipes_then_stalls_still_hits_the_deadline in tests/task-workstream-session-worker.test.py exercises this same case and is a genuine regression (fails without the fix — a bare process.wait() blocks the full 5s).

Both wedge-path P1s I care about (blocking readline() on partial output, and unbounded post-EOF process.wait()) are now closed at this head.

One unrelated note, not blocking: running the full local test suite in my sandbox, test_codex_notifier_never_submits_a_watcher_claim_to_live_core flaked (failed 2/3, passed 1/3) — looks like timing sensitivity in the fake-tmux-binary polling harness under sandbox load, not a deterministic regression from this diff's small task-notifier.sh guard clause (confirmed the diff there is a 4-line early-return, unrelated to the bounded-runtime fix). Flagging in case others see it too, but I'm not blocking on it since hosted CI is the authoritative signal for that suite and it wasn't reported red there.

[qingyun-wu]

Re-reviewed exact head a278e24f. The EOF-then-stall escape is closed. Clearing my CHANGES_REQUESTED.

Verified by running the escape against both heads, not by reading the diff alone. I loaded session-worker.py from each head directly and called _run_process_bounded with a child that closes stdout+stderr then hangs, budgets 0.3s hard / 0.2s stall:

=== OLD head 8a0a1034 (the escape I flagged) ===
NO TIMEOUT -> returned 0 after 5.03s  [ESCAPE OPEN]

=== NEW head a278e24f (this fix) ===
TimeoutError at 0.22s :: provider made no progress for 0.2s  [BOUNDED]

The old arm is the control — it reproduces the wedge, so the new arm's pass is attributable to the fix rather than to the harness.

Indefinite variant (child closes both pipes then while True: sleep(1), i.e. never exits) at a278e24f:

TimeoutError at 0.22s :: provider made no progress for 0.2s [BOUNDED]
child pid 26190 still alive after return? False  [TERMINATED]

That second line is the one that matters for the wedge claim: the deadline doesn't just return, it reaches _terminate_process_group() and the child is actually gone. No orphan holding the worker slot.

The implementation is the right shape. After the selector drains, process.wait(timeout=min(0.2, stall_timeout)) in slices, re-checking both budgets each slice and raising TimeoutError (which the outer except BaseException turns into a group terminate). Enforcement now ends at process exit, not pipe EOF. I checked the degenerate input too: a non-positive stall_timeout makes the slice non-blocking, but the now - last_progress >= stall_timeout branch then trips immediately, so it fails closed rather than busy-spinning.

The regression test is a real one. test_closes_pipes_then_stalls_still_hits_the_deadline — child does os.close(1); os.close(2); sleep(5), asserts TimeoutError in under 2s. Against the old implementation that path returns rc=0 at 5.03s and never raises, so the test fails without the fix. Both wedge routes (partial line, pipe close) are now covered.

Scope of this approval, stated plainly: it clears the timeout/wedge blocker I raised — the bounded-runtime fail-closed guarantee, which is what my CHANGES_REQUESTED was about. I re-verified that specific boundary at this head; I did not re-audit the full tier-enforcement diff from scratch this pass.

CI is not green yet, and this approval is not a substitute for it. At a278e24f, diff coverage >= 95% (python) and tsc + tests (clean install) are both pending (in flight, not failing — a pending conclusion is never red), and license/cla is unsigned. mergeStateStatus is still BLOCKED. Merge needs those plus the second distinct approval.

Nice fix — the slice-and-recheck shape is exactly right.

Reviewed by Qingyun's Sutando.

[john-the-dev]

Cycling to clear a wedged license/cla check — the update-branch merge stopped cla-assistant re-posting a passing status; all authors are already CLA-signed (verified: #2735 merged green with the identical author/co-author set). Reopening immediately; the bassil+qingyun approvals at a278e24 persist (dismiss_stale=false, no new commit).

[john-the-dev]

@cla-assistant check

[john-the-dev]

recheck

[john-the-dev]

recheck

[github-actions]

@cla-assistant check

[qingyun-wu]

Re-approving at the new head 6557631d after the CLA force-push. My approval carries over — verified, not assumed.

You said the code is byte-identical to what I approved at a278e24f. I checked rather than taking it on faith, and I checked it twice because my first instrument was wrong:

• Tree SHA — wrong test. a278e24f → 0acb56fc…, 6557631d → cca5558c…. They differ, but that is expected after a rebase: the tree reflects all of main, not your diff. Reporting "trees differ, claim unverified" off that would have been a false alarm.
• Blob SHA of the reviewed files — right test. Both are identical at the two heads:

skills/task-workstream-sessions/scripts/session-worker.py   4573ddbac8dadb8191407d83528c0b632216dafb   (both)
tests/task-workstream-session-worker.test.py               f840bccf382fc7f1b35fb320374b1a0fb22d76c2   (both)

So the bounded-runtime fix and its regression test are the exact bytes I verified. The evidence from that review stands unchanged: at the old head the EOF-then-stall child sailed past the deadline (rc=0 after 5.03s); with this code it is bounded at 0.22s and the child is confirmed terminated, so _terminate_process_group() is genuinely reached.

I have not re-run the reproduction against this head — the inputs are identical bytes, so it would be testing the same code twice rather than testing anything new. Saying so explicitly since "re-verified" should mean a specific thing.

Scope unchanged: this clears the timeout/wedge boundary I raised. mergeStateStatus is UNSTABLE (checks in flight at the new head) and the second distinct approval is still needed — this approval is not a substitute for either.

Reviewed by Qingyun's Sutando.