workflows: agent startup (session creation + extension binding) is not abortable

[tt-a1i]

Description

Verified by read-only audit (seal/gpt-5.6-sol subagent, verdict: CONFIRMED — low severity, lifecycle hardening).

Mechanism

• runAgent awaits sessionFactory ?? createAgentSession (runner.ts:532-544) then bindChildSessionExtensions (runner.ts:545), which awaits session.bindExtensions({ mode: "print" }) (extensions/shared/child-session.ts:215-219) — binding serially awaits session_start and resources_discover extension handlers (pi-coding-agent/dist/core/agent-session.js:1741-1762).
• The abort listener is installed only afterward (runner.ts:652-684).
• Concrete handlers can be slow: extensions/file-search/index.ts:144-174 awaits binary initialization, which can probe subprocesses, download over HTTPS, and invoke tar (extensions/file-search/src/binaries.ts:182-220,327-407) with internal timeouts.

Impact (bounded)

Cancellation cannot interrupt either startup await; a genuinely hung handler can outlive the controller's 8-second settlement deadline (controller.ts:165-187). However, once startup completes, the late signal.aborted check (runner.ts:680-683) aborts/disposes the session and if (!aborted) skips prompt() (runner.ts:689-704) — the agent does not continue running after cancellation.

Net impact: delayed/unbounded startup cleanup and possible settlement timeout, not post-cancellation prompting. Also, a startup rejection caused by cancellation is caught as aborted: false, slightly misclassifying cancellation (still settles).

Suggested fix

Install/observe the signal before session creation and race session creation/binding against an abort promise, disposing any session created after cancellation. Return an aborted outcome from startup.

Found by automated workflow audit (run wf_56028a5b018b).

[CuSO41108]

Hi, I’d like to take #116.

I plan to keep the scope focused on cancellation during workflow child-agent startup: session creation, extension binding, disposing any session created after cancellation, and returning an explicit aborted outcome.

I’ll add deterministic regression tests covering cancellation before startup, during session creation/binding, and ensuring no prompt is issued after cancellation. I won’t broaden this to unrelated Git or process-management cancellation paths.

If this scope matches your intent, please assign the issue to me.