@bastani/atomic 0.9.39 → 0.9.40-alpha.2

package/dist/builtin/intercom/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@bastani/intercom",
-  "version": "0.9.39",
+  "version": "0.9.40-alpha.2",
   "private": true,
   "description": "Atomic extension providing a private coordination channel between parent and child agent sessions. Fork of: https://github.com/nicobailon/pi-intercom",
   "contributors": [

package/dist/builtin/intercom/retry-policy.ts

@@ -8,3 +8,7 @@ export const RETRY_IDENTITY_TTL_MS = ASK_REPLY_TIMEOUT_MS + RETRY_IDENTITY_RETRY
 export const DELIVERED_MESSAGE_TTL_MS = RETRY_IDENTITY_TTL_MS + RETRY_IDENTITY_RETRY_OPPORTUNITY_MS;
 /** Three reconnect attempts, used independently before initialization and during delivery. */
 export const RECONNECT_DELAYS_MS = [1_000, 2_000, 5_000] as const;
+/** How long a sender waits for one send's outcome before its client gives up. */
+export const SEND_RESPONSE_TIMEOUT_MS = 10_000;
+/** The broker answers an unconfirmed save before the sender's own wait ends, so the sender learns the outcome is uncertain. */
+export const RECIPIENT_RECEIPT_TIMEOUT_MS = 8_000;

package/dist/builtin/intercom/session-target.ts

@@ -4,6 +4,7 @@ export type SessionTargetResolution<T extends Pick<SessionInfo, "id" | "name"> =
   | { kind: "resolved"; session: T }
   | { kind: "ambiguous_name"; matches: readonly T[] }
   | { kind: "ambiguous_id_prefix"; matches: readonly T[] }
+  | { kind: "ambiguous_session_id"; matches: readonly T[] }
   | { kind: "not_found" };
 
 const UUID_PATTERN = /^[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$/i;
@@ -42,6 +43,24 @@ export function resolveSessionTarget<T extends Pick<SessionInfo, "id" | "name">>
   return { kind: "not_found" };
 }
 
+/**
+ * #3760: a host (Atomic) session id addresses the one candidate registered for it. Only the broker knows
+ * which host session registered each Intercom session, so it supplies the lookup; this applies only after
+ * Intercom ids, names and id prefixes found nothing, so it never shadows them.
+ */
+export function resolveSessionTargetByHostSessionId<T extends Pick<SessionInfo, "id" | "name">>(
+  sessions: readonly T[],
+  target: string,
+  hostSessionIdOf: (session: T) => string | undefined,
+): SessionTargetResolution<T> {
+  const hostSessionId = target.trim();
+  if (!hostSessionId) return { kind: "not_found" };
+  const matches = sessions.filter((session) => hostSessionIdOf(session) === hostSessionId);
+  if (matches.length === 1) return { kind: "resolved", session: matches[0]! };
+  if (matches.length > 1) return { kind: "ambiguous_session_id", matches };
+  return { kind: "not_found" };
+}
+
 export function sessionTargetFailureReason(
   target: string,
   resolution: Exclude<SessionTargetResolution<Pick<SessionInfo, "id" | "name">>, { kind: "resolved" }>,
@@ -54,6 +73,11 @@ export function sessionTargetFailureReason(
 			.map((session) => `${session.name ?? "unnamed"} (${session.id})`)
 			.join(", ")}. Use the full UUID.`;
 	}
+	if (resolution.kind === "ambiguous_session_id") {
+		return `Session ID "${target}" is registered by more than one Intercom session: ${resolution.matches
+			.map((session) => `${session.name ?? "unnamed"} (${session.id})`)
+			.join(", ")}. Use the Intercom session ID shown by intercom list.`;
+	}
   return "Session not found";
 }
 

package/dist/builtin/intercom/types.ts

@@ -128,18 +128,51 @@ export type ClientMessage =
 			session: Omit<SessionInfo, "id">;
 			/** Internal host-owned identity retained across broker reconnects. */
 			returnAddress?: string;
+			/**
+			 * The Intercom session id this session held before a restart or reconnect (#3760). The broker grants it
+			 * only when no live session holds it and it was not last held under another return address.
+			 */
+			preferredSessionId?: string;
 			/** Immutable session origin; separate from mutable group memberships. Legacy clients use session.group. */
 			registrationGroup?: string;
 			supervisor?: SupervisorRegistration;
 			supervisorOwnerToken?: string;
+			/** #3761: this recipient sends `received` once it has saved each message; `delivered` waits for it. */
+			acknowledgesReceipt?: true;
 	  }
 	| { type: "unregister" }
+	/** #3761: the recipient saved this message; it ignores a copy of it sent again. */
+	| { type: "received"; messageId: string }
   | { type: "list"; requestId: string; group?: string }
 	| { type: "list_groups"; requestId: string }
 	| { type: "join_group"; requestId: string; group: string }
 	| { type: "leave_group"; requestId: string; group?: string }
   | { type: "authorize_supervisor"; requestId: string; childName: string; capability?: string }
-  | { type: "send" | "supervisor_send"; to: string; logicalTarget?: string; requirePendingReply?: true; expectedRecipientId?: string; resolveReplyTarget?: true; message: Message; attemptId?: string }
+  /**
+   * #3760: the supervisor that holds `capability` for a child it is restoring, or is about to restore, holds sends to
+   * that child's name and `aliases` (its Atomic session id and pre-restart Intercom id) until the child registers
+   * with the capability. A `dormant` hold only keeps the child addressable until the supervisor that restores it
+   * reserves the same child and group, which takes the hold over together with the sends held so far.
+   */
+  | { type: "reserve_restoring_recipient"; requestId: string; capability: string; group?: string; aliases?: string[]; dormant?: boolean }
+  /**
+   * #3760: end that hold. With `gone` (the reason), held and later senders are told the child is gone. With `refusal`,
+   * the senders held now are told that reason instead and later ones are routed normally. Otherwise held sends are
+   * routed normally.
+   */
+  | { type: "release_restoring_recipient"; requestId: string; capability: string; gone?: string; refusal?: string }
+  | {
+      type: "send" | "supervisor_send";
+      to: string;
+      logicalTarget?: string;
+      requirePendingReply?: true;
+      expectedRecipientId?: string;
+      resolveReplyTarget?: true;
+      /** The sender understands `send_held` and may wait past its usual acknowledgement timeout (#3760). */
+      awaitRestoringRecipient?: true;
+      message: Message;
+      attemptId?: string;
+    }
 	| {
 			type: "send_pending_stage_notification";
 			runId: string;
@@ -151,7 +184,17 @@ export type ClientMessage =
 			attemptId?: string;
 	  }
 	| { type: "pending_stage_notification_result"; requestId: string; delivered: boolean }
- | { type: "register_pending_stage_route"; runId: string; group: string; capability: string; stages?: WorkflowStageRosterAnnouncement[]; possibleStages?: WorkflowPossibleStageAnnouncement[]; parent?: WorkflowRunParentAnnouncement }
+ | {
+		type: "register_pending_stage_route";
+		runId: string;
+		group: string;
+		capability: string;
+		stages?: WorkflowStageRosterAnnouncement[];
+		possibleStages?: WorkflowPossibleStageAnnouncement[];
+		parent?: WorkflowRunParentAnnouncement;
+		/** Interrupted run queued by its restarted owner before resume; yields to the process that resumes it (#3760). */
+		dormant?: true;
+	}
   | {
       type: "register_live_workflow_stage_route";
       requestId: string;
@@ -181,7 +224,13 @@ export type ClientMessage =
     };
 
 export type BrokerMessage =
-  | { type: "registered"; sessionId: string; supervisorSessionId?: string }
+	| {
+			type: "registered";
+			sessionId: string;
+			supervisorSessionId?: string;
+			/** #3761: echoed only to a client that advertised it; that client may now send `received`. */
+			acknowledgesReceipt?: true;
+	  }
   | { type: "registration_failed"; reason: string; code?: LiveWorkflowStageRouteRefusalCode }
   | { type: "question_target"; messageId: string; attemptId: string; sessionId: string }
  | { type: "sessions"; requestId: string; sessions: SessionInfo[]; workflowStages?: WorkflowStageRosterEntry[]; workflowFutureStages?: WorkflowFutureStageRosterEntry[] }
@@ -202,6 +251,8 @@ export type BrokerMessage =
 			live?: boolean;
 	  }
   | { type: "live_workflow_stage_route_registered"; requestId: string }
+	/** A dormant route's run was resumed by another process, which now owns the run's routes (#3760). */
+	| { type: "pending_stage_route_revoked"; runId: string }
   | { type: "presence_update"; session: SessionInfo }
   | { type: "session_joined"; session: SessionInfo }
   | { type: "session_left"; sessionId: string }
@@ -211,4 +262,7 @@ export type BrokerMessage =
   | { type: "error"; error: string }
   | { type: "delivered"; messageId: string; attemptId?: string }
 	| { type: "queued"; messageId: string; attemptId?: string; target: string; position: number }
+	/** #3760: the send is held for a subagent that is being restored; wait up to `timeoutMs` for its outcome. */
+	| { type: "send_held"; messageId: string; attemptId?: string; timeoutMs: number }
+	| { type: "restoring_recipient_ack"; requestId: string; error?: string }
 	| { type: "delivery_failed"; messageId: string; reason: string; reasonCode?: "message_id_conflict" | "session_not_found"; attemptId?: string };

package/dist/builtin/mcp/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@bastani/mcp",
-  "version": "0.9.39",
+  "version": "0.9.40-alpha.2",
   "private": true,
   "description": "Atomic's pi-compatible MCP integration for server connections, OAuth, tools, resources, and terminal management.",
   "contributors": [

package/dist/builtin/subagents/CHANGELOG.md

@@ -2,6 +2,37 @@
 
 ## [Unreleased]
 
+## [0.9.40-alpha.1] - 2026-10-20
+
+### Breaking Changes
+
+- Removed the `kill` action from the `subagent` tool. Replace `subagent({ action: "kill", id })` with `subagent({ action: "quit", id })`, which stops the child gracefully and keeps it resumable. Calls with `action: "kill"` or the earlier `action: "interrupt"` are rejected with an error that names `quit` as the replacement ([#3760](https://github.com/bastani-inc/atomic/issues/3760)).
+
+### Added
+
+- Added workflow-style run control to the `subagent` tool: `pause` stops a child and holds its queued messages until resume, `quit` stops it gracefully, and `resume` continues it from its own saved session under the same child id, Intercom name, and group. `pause` and `quit` accept `all: true` and also reach parallel children still queued behind their concurrency limit, which then start only when resumed, and `resume` accepts an optional `message`: a paused, quit, or interrupted child receives it once as its next prompt and then continues where it left off, and a completed or failed child receives it as one fresh prompt. Without `message`, the child is asked to continue where it left off, including a completed or failed child. A resumed child of a parallel run waits for a slot under that run's concurrency limit, and keeps its `worktree: true` worktree until it finishes; a paused or quit child holds no slot, and its worktree is kept only while it has uncommitted or untracked changes or commits that are not in the run's base. Resume continues in a kept worktree, or recreates a removed one from the run's base; a resume that fails keeps the worktree, its changes, and its branch. Steering and follow-up messages a child had queued when it was paused or quit are delivered once, in order, when it resumes, before the resume `message`. An SDK session without a task host records its subagents the same way, so `pause`, `resume` and `quit` work there too, also after the session is reopened; a child it resumes runs in the background and reports through a completion notice. A child paused or quit before it read its task or the resume message keeps them, and resume delivers them. `id` accepts the child id, task id, Intercom name, or a single-child run id ([#3760](https://github.com/bastani-inc/atomic/issues/3760)).
+- Paused, quit, interrupted, completed, and failed children can be resumed, including children of a session you closed or switched away from (Atomic exit or crash, `/new`, `/resume` to another session, `/fork`). Children cancelled for good (owner or batch cancellation, a `/tasks` stop, the removed `kill` action) or reported gone after a restart are terminal, and `resume` on them returns an error that says why ([#3760](https://github.com/bastani-inc/atomic/issues/3760)).
+- Background subagent launch cards now show the child's latest state, also after you reopen the session (`/resume` or `atomic --session <id>`) or view a workflow stage's transcript: running, paused, paused with its workflow stage, quit, or interrupted (resumable), completed, failed, or terminal (killed, gone after a restart, or its workflow stage ended). Expanding a card shows the end of the child's saved transcript. A resumed child continues in its original card, marked resumed, and replayed `pause`, `resume`, and `quit` calls render as their results, or as errors when they were rejected ([#3760](https://github.com/bastani-inc/atomic/issues/3760)).
+
+### Changed
+
+- Updated the bundled Cua Driver skill to upstream `cua-driver-rs-v0.36.0`. It now starts with an efficient loop: targeted `get_window_state` reads with `query`, acting by `element_token`, batching actions with `run_steps` or `run_script`, re-reading only changes with `since:"latest"`, and verifying at checkpoints instead of after every action. It also covers opening local files with `launch_app`, browser fallbacks when browser tools refuse in the background, and macOS editor recipes.
+- When a workflow stage closes for good (the stage finished, or its run ended or was cancelled), every subagent it launched becomes terminal, whether running, paused, quit, completed, or failed, and `resume` on them returns an error that says their workflow stage ended. A quit child stays resumable only while the session or stage that launched it can still resume it. `quit` also accepts a child paused with its workflow stage, and `pause` reports such a child as already paused. Pausing or quitting a workflow run, Atomic exiting, switching sessions, and an interrupted stage leave the stage's children resumable: `resume` continues them, and resuming the run after Atomic restarts restores them with the stage ([#3760](https://github.com/bastani-inc/atomic/issues/3760)). A stage blocked by a recoverable failure, such as a rate limit or provider outage that leaves its run resumable, keeps its paused and quit subagents resumable until the run is killed, cancelled, or ends without staying resumable; then they end with the stage.
+
+### Fixed
+
+- Background subagents that were still running when Atomic exited are now relaunched from their own sessions when you resume the session (`atomic --session <id>` or `/resume`) or resume a workflow stage that launched them. They keep their original Intercom name and group and get fresh supervisor authorization, and Intercom messages sent to it by any session in its group wait for it from the moment the resumed session starts (or, for a stage's subagent, from the moment the interrupted run becomes addressable) until it has been restored. Only the session that launched a child restores it: a fork of that session (`/fork`, `atomic --fork`, or a branched session) copies the child's record but never relaunches, waits for, or reports the child. If a child cannot be restored, the resumed agent is told explicitly that it is gone, once: the child is then recorded as gone, so later resumes neither retry it nor repeat the notice ([#3760](https://github.com/bastani-inc/atomic/issues/3760)).
+- On Windows, removing a `worktree: true` worktree now removes its directory. Its `node_modules` junction is unlinked first, so Git for Windows no longer leaves the directory behind, and older Git versions no longer delete the main checkout's `node_modules` through the junction.
+- A `worktree: true` child resumed after an Atomic restart saves its tracked and untracked edits as a patch in its run's `worktree-diffs` directory before its worktree is removed, as a child of a fresh run does.
+- Resuming a `worktree: true` child whose worktree was already removed, such as a completed child, now restores the edits it saved as a patch before it continues, so its earlier work is not lost. Each run saves its patches in its own `worktree-diffs/<run id>` directory, and each execution of a resumed child writes its own patch (`task-<n>-<agent>.<execution>.patch`) instead of overwriting the earlier one. Patches now include binary changes.
+- A subagent that an SDK session without a task host resumed now stops when that session closes, as the original launch does. Reopening the session relaunches it automatically, as it does a task-host child, and the steering and follow-up messages it had queued and not read are delivered once, in order. A task-host child whose session or workflow stage closes now keeps its unread steering and follow-up messages the same way, and restoring or resuming it delivers them once, in order, instead of losing them.
+- Opening a fork no longer changes the original session's subagent launch cards back to an older state copied into the fork, such as showing a completed child as running.
+- `pause` or `quit` of a subagent that completes just before the stop takes effect now reports that it completed instead of "Paused", and Intercom messages sent to it are no longer held until a resume ([#3784](https://github.com/bastani-inc/atomic/pull/3784)).
+- A parallel subagent paused or quit while it still waited for a free slot can now be resumed after Atomic restarts, and one still waiting when Atomic exited starts when its session reopens, instead of being reported unrestorable or gone. It starts as a new launch under the same child id, Intercom name, and group, with its original agent definition, task, working directory or worktree, model, and skills, and a `context: "fork"` child starts on the parent conversation its launch branched; if that branch can no longer be reopened, the child is reported gone rather than started without it. This holds in task-host and SDK sessions alike ([#3784](https://github.com/bastani-inc/atomic/pull/3784)).
+- Subagents of a workflow stage whose run is killed while it waits, after Atomic restarts, for `/workflow resume` now end with the run: `resume` returns "its workflow stage ended", their cards no longer show them as resumable, and reopening the stage's session no longer restores them ([#3784](https://github.com/bastani-inc/atomic/pull/3784)).
+- A subagent relaunched from its own session after Atomic restarts, or resumed with `resume`, now runs on the agent definition it was launched with: a user agent is no longer replaced by a project agent of the same name. A child launched with `context: "fork"` also keeps its Intercom bridge instructions under `intercomBridge.mode: "fork-only"`. Children recorded by an earlier version keep the previous lookup ([#3784](https://github.com/bastani-inc/atomic/pull/3784)).
+- A queued parallel subagent that inherited its parent's model and thinking level now keeps them when it starts after Atomic restarts, instead of taking whatever model and thinking level the parent switched to meanwhile. If that model is no longer available, resume reports the child as gone instead of starting it on the parent's current model. A child restored or resumed from its own session also falls back to the model it was launched with, not the parent's current one, and a child launched outside any Intercom group no longer joins a group the parent joined later ([#3784](https://github.com/bastani-inc/atomic/pull/3784)).
+
 ## [0.9.39] - 2026-10-19
 
 ### Fixed

package/dist/builtin/subagents/README.md

@@ -183,7 +183,9 @@ subagent({ agent: "codebase-analyzer", task: "Trace authentication.", wait: { ki
 subagent({ agent: "codebase-analyzer", task: "Trace authentication.", wait: { kind: "foreground", budgetMs: 30000 } })
 subagent({ action: "wait", id: taskId })
 subagent({ action: "status", id: taskId })
-subagent({ action: "kill", id: taskId })
+subagent({ action: "pause", id: taskId })
+subagent({ action: "resume", id: taskId, message: "Focus on the failing test." })
+subagent({ action: "quit", id: taskId })
 ```
 
 In owner-bound sessions, omitted `wait` means background. Explicit foreground waits use the owner's agent observation budget, normally 30 seconds, unless overridden. Expiry releases the caller, not the execution. Wait or inspect the returned task ID instead of launching a duplicate. Existing SDK callers without an owner retain their original execution path.
@@ -202,7 +204,7 @@ clarify → gather context → worker → fresh reviewers → worker
 
 Packaged `worker` defaults to forked context when a launch omits `context`; every other builtin runs fresh. Pass `context: "fresh"` when you intentionally want a fresh `worker` run.
 
-Child-safety boundaries are enforced at runtime by typed admission policy. In-process child sessions load bundled extensions through normal discovery. The `subagent` tool may therefore be registered when the child's active tool selection permits it, including the default no-allowlist case; an explicit allowlist may omit it. Tool presence does not grant fanout: fanout is authorized only when the resolved builtin `tools` list includes `subagent`. Typed admission policy lets a non-fanout child use only `list`, `get`, and `status`; delegation and `kill` receive the fanout refusal. A management-restricted child is also refused `create`, `update`, and `delete`. The bundled `pi-subagents` skill remains parent-only and is stripped from child prompts, including fanout-authorized children. No admitted child may delegate or control another child: launches and `kill` are refused for every child regardless of its fanout authorization. Children receive boundary instructions that they are not the parent orchestrator and must complete their assigned task directly. Forked child context filtering also removes parent-only subagent artifacts (including old hidden orchestration-instruction messages, slash/status/control messages, and prior parent `subagent` tool-call/tool-result history) while preserving ordinary prose and unrelated tool calls/results.
+Child-safety boundaries are enforced at runtime by typed admission policy. In-process child sessions load bundled extensions through normal discovery. The `subagent` tool may therefore be registered when the child's active tool selection permits it, including the default no-allowlist case; an explicit allowlist may omit it. Tool presence does not grant fanout: fanout is authorized only when the resolved builtin `tools` list includes `subagent`. Typed admission policy lets a non-fanout child use only `list`, `get`, `status`, and `wait`; delegation and run control (`pause`, `resume`, `quit`) receive the fanout refusal. A management-restricted child is also refused `create`, `update`, and `delete`. The bundled `pi-subagents` skill remains parent-only and is stripped from child prompts, including fanout-authorized children. No admitted child may delegate or control another child: launches and run control are refused for every child regardless of its fanout authorization. Children receive boundary instructions that they are not the parent orchestrator and must complete their assigned task directly. Forked child context filtering also removes parent-only subagent artifacts (including old hidden orchestration-instruction messages, slash/status/control messages, and prior parent `subagent` tool-call/tool-result history) while preserving ordinary prose and unrelated tool calls/results.
 
 
 
@@ -234,13 +236,13 @@ Child-side routine completion handoffs are still not expected. In parallel runs,
 
 Children can also talk to each other. Children launched in one parallel set (or with the same explicit `group`) share an Intercom group, and children launched from a workflow stage inherit that stage's invocation group. `intercom({ action: "list" })` shows live siblings, and ordinary `send`/`ask` reaches them directly: a locator hands paths to an analyzer, writers agree on file ownership or who runs a shared suite, a debugger reuses a sibling's reproduction, or one reviewer challenges another's finding before each returns its own verdict. `contact_supervisor` stays reserved for the supervisor. Peers do not coordinate spontaneously, so name the peers and the expected, bounded exchange in each task prompt. Peer asks and one blocking supervisor request may wait concurrently in the same child.
 
-An exact-child probe/commit handshake may release parallel foreground observations, including queued slots, so the parent can respond. It does not end any execution or spend a running concurrency slot. Active siblings keep working, queued siblings start once capacity becomes available, and worktrees remain until their owners finish. Do not relaunch children to answer an ask. Targeted kill, explicit batch cancellation, and owner closure remain separate controls.
+An exact-child probe/commit handshake may release parallel foreground observations, including queued slots, so the parent can respond. It does not end any execution or spend a running concurrency slot. Active siblings keep working, queued siblings start once capacity becomes available, and worktrees remain until their owners finish. Do not relaunch children to answer an ask. Targeted `pause`/`quit`, explicit batch cancellation, and owner closure remain separate controls.
 
 Single-child launches retain their existing terminal parent-ask handoff: the exact live child ends before broker send or waiter admission and the parent receives the verbatim question, ordered attachments, identity, and `[TASK_CONTEXT]` for a fresh child. The bridge still obtains each child's capability during admission; the child connects only when it uses Intercom.
 
 Parent-side Atomic sends grouped completion results through Intercom: one grouped message per foreground parent `subagent` run and one per detached child completion while its owning session remains live. When a workflow stage completes, Atomic cancels its still-running detached children and suppresses their late findings and completion notifications instead of forwarding them to the parent/main chat. Intercom-confirmed delivery returns a compact receipt with artifact/session paths; without that confirmation, the normal full output is preserved. Grouped messages include child Intercom targets and full child summaries.
 
-If a child appears stalled, needs-attention notices can show up in the parent session with useful next actions, such as checking `subagent({ action: "status" })`, killing the run, or nudging the child.
+If a child appears stalled, needs-attention notices can show up in the parent session with useful next actions, such as checking `subagent({ action: "status" })`, quitting the child, or nudging it.
 
 If messages do not show up, check the bridge from the intercom side with `intercom({ action: "status" })`.
 
@@ -438,7 +440,7 @@ What the bundled skill covers:
 - **Role-agent prompting guidance**: compact contract prompts instead of long scripts, what to include in role-specific meta prompts, and retrieval budgets for researchers
 - **Safety boundaries**: child agents must not run subagents, must not invent intercom targets, and must escalate unapproved decisions
 - **Intercom conventions**: when to ask vs send, and how parent-side result delivery works with `pi-intercom`
-- **Control signals**: attention signals, terminal kills, and status
+- **Control signals**: attention signals, pause/resume/quit run control, and status
 
 If you are writing an agent that orchestrates subagents, the bundled skill helps it behave correctly without guessing the patterns. If you are a human user, you do not need to read it directly; the README and prompt shortcuts encode the same workflows in user-facing form.
 
@@ -528,11 +530,11 @@ Agent definitions are not loaded into context by default. Management actions let
 |-------|------|---------|-------------|
 | `agent` | string | - | Agent name for single mode, or target for management actions. |
 | `task` | string | - | Task string for single mode. |
-| `action` | string | - | `list`, `get`, `create`, `update`, `delete`, `status`, `wait`, or `kill`. |
+| `action` | string | - | `list`, `get`, `create`, `update`, `delete`, `status`, `wait`, `pause`, `resume`, or `quit`. `kill` and `interrupt` were removed and are rejected with an error naming `quit`. |
 | `config` | object/string | - | Agent config for create/update. |
 | `wait` | object | background in owner-bound sessions | `{ kind: "background" }` yields after admission; `{ kind: "foreground", budgetMs?: number }` waits before automatically yielding. |
 | `budgetMs` | number | owner wait policy | Observation budget for `action: "wait"`; not a child execution deadline. |
-| `id` | string | - | Task ID returned by an owner-bound launch for `wait`, `status`, or `kill`. |
+| `id` | string | - | Task ID returned by an owner-bound launch for `wait` or `status`; for `pause`, `resume`, and `quit` also the child id (`<runId>:<index>`), Intercom name, or a single-child run id. |
 | `output` | `string \| false` | agent default | Override single-agent output file. |
 | `outputMode` | `"inline" \| "file-only"` | `inline` | Return saved output inline or as a concise saved-file reference. `file-only` requires an `output` path. |
 | `reads` | `string[] \| false` | - | Single-agent files to read before execution, or `false` to disable. Relative paths resolve against the effective child `cwd`; absolute paths pass through. |
@@ -561,10 +563,14 @@ Status and control actions:
 ```ts
 subagent({ action: "status" })
 subagent({ action: "status", id: "<run-id>" })
-subagent({ action: "kill", id: "<run-id>" })
+subagent({ action: "pause", id: "<child-id>" })
+subagent({ action: "pause", all: true })
+subagent({ action: "resume", id: "<child-id>", message: "optional steer" })
+subagent({ action: "quit", id: "<child-id>" })
+subagent({ action: "quit", all: true })
 ```
 
-Completed, killed, interrupted, and single-child terminal-handoff children cannot be revived by a prior run ID; follow-up work requires a fresh launch with explicit context. A parallel child waiting for a reply is not terminal and continues in its original execution. Parent cancellation of a still-running child uses the interrupted/abort state: receipts and progress present it as cancelled rather than failed, persisted metadata keeps the abort cause, and bounded partial findings remain available. Migrate old subagent calls from `action: "interrupt"` to `action: "kill"`; the old action is rejected. Kill is terminal and cannot be resumed. Workflow controls use `pause`; host interrupt APIs are unchanged.
+`pause` stops a child and holds its queued messages until `resume`; `quit` stops it gracefully, including a child already paused by you or with its workflow stage. Both stay resumable while the session or workflow stage that launched the child can still resume it, as do children stopped because their workflow stage was paused or quit, including by Atomic exiting or a session switch. `resume` reopens the child's own session under the same id and Intercom name. A paused, quit, or interrupted child receives `message` once as its next prompt and then continues where it left off; a completed or failed child receives `message` as one fresh prompt. Without `message`, every resumable child, including a completed or failed one, is asked to continue where it left off. Children cancelled for good (owner or batch cancellation, including a `/tasks` stop, and the removed `kill` action), children whose workflow stage ended (the stage finished, or its run ended or was cancelled; this covers all of that stage's children, including ones you paused or quit), and children reported gone after a restart cannot be resumed: `resume` returns an error that says why, and follow-up work requires a fresh launch with explicit context. A parallel child waiting for a reply is not terminal and continues in its original execution. Parent cancellation of a still-running child uses the interrupted/abort state: receipts and progress present it as cancelled rather than failed, persisted metadata keeps the abort cause, and bounded partial findings remain available. Migrate old subagent calls from `action: "kill"` or `action: "interrupt"` to `action: "quit"`; the old actions are rejected with `The subagent action "kill" was removed. Use { action: "quit", id } to stop a child gracefully; it stays resumable with { action: "resume", id, message? }.` (naming the action that was used). Host interrupt APIs are unchanged.
 
 ## Worktree isolation
 
@@ -690,7 +696,7 @@ Foreground runs persist their session and user-facing artifacts beside the paren
   run-history.jsonl
 ```
 
-Task-ID status, wait, and kill resolve the same owner as launch. Run-ID status uses the existing Rust subagent registry. Owner-bound completion delivery uses persisted intent and acknowledgement records in session history; no second PID registry or execution is created for the UI.
+Task-ID status, wait, pause, resume, and quit resolve the same owner as launch. Run-ID status uses the existing Rust subagent registry. Owner-bound completion delivery uses persisted intent and acknowledgement records in session history; no second PID registry or execution is created for the UI.
 
 ## Completion and output
 
@@ -725,7 +731,7 @@ This is disabled by default. Session data may contain source code, paths, enviro
 
 ## Delegation boundary
 
-Delegation is exactly one level deep, and nothing configures it. A top-level session, main chat or a workflow stage, may call `subagent`. A session that was itself admitted as a subagent child may not: every launch and `kill` it attempts is refused with guidance to complete its assigned task directly. The observing actions `list`, `get`, and `status` stay available to a child. Child sessions retain bundled workflow definitions as resources but do not load the workflows extension or expose its `workflow` tool; orchestration stays owned by the parent session.
+Delegation is exactly one level deep, and nothing configures it. A top-level session, main chat or a workflow stage, may call `subagent`. A session that was itself admitted as a subagent child may not: every launch and run control (`pause`, `resume`, `quit`) it attempts is refused with guidance to complete its assigned task directly. The observing actions `list`, `get`, `status`, and `wait` stay available to a child. Child sessions retain bundled workflow definitions as resources but do not load the workflows extension or expose its `workflow` tool; orchestration stays owned by the parent session.
 
 There is no configuration option, agent frontmatter field, or tool parameter for the delegation level. The rule is enforced twice: the subagent executor refuses a child before any run starts, and the Rust `SubagentControl` admission door refuses a child deeper than the single permitted level. Admitted depth is typed admission state and is not inherited through an environment variable.
 
@@ -782,7 +788,7 @@ The main runtime files are:
 |------|---------|
 | `src/extension/index.ts` | Extension registration, tool registration, message/render wiring. |
 | `src/agents/agents.ts` | Agent discovery and frontmatter parsing. |
-| `src/runs/foreground/subagent-executor.ts` | Main execution routing for single, parallel, management, status, and kill actions. |
+| `src/runs/foreground/subagent-executor.ts` | Main execution routing for single, parallel, management, status, and run-control actions. |
 | `src/runs/foreground/execution.ts` | Core foreground `runSync` handling. |
 | `src/runs/foreground/notify.ts` | Completion-notification delivery for a detached Intercom child. |
 | `src/runs/foreground/completion-notification.ts` | Local completion acknowledgement and ordering barrier for detached children. |

package/dist/builtin/subagents/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@bastani/subagents",
-  "version": "0.9.39",
+  "version": "0.9.40-alpha.2",
   "private": true,
   "description": "Atomic extension for delegating tasks to subagents with parallel execution. Fork of: https://github.com/nicobailon/pi-subagents",
   "contributors": [

package/dist/builtin/subagents/skills/agent-browser/SKILL.md

@@ -4,7 +4,7 @@ description: Browser automation CLI for AI agents. Use when the user needs to in
 hidden: true
 metadata:
     github-path: skills/agent-browser
-    github-ref: refs/tags/v0.38.2
+    github-ref: refs/tags/v0.39.1
     github-repo: https://github.com/vercel-labs/agent-browser
     github-tree-sha: 82def67855a0d2aad7794207951820fa5422fdb0
 name: agent-browser

package/dist/builtin/subagents/skills/cua-driver/BROWSER.md

@@ -109,7 +109,13 @@ title looks close.
 `get_browser_state` is strictly read-only. It never launches a browser,
 changes a profile, enables remote debugging, or accepts a consent prompt. If
 it returns `browser_requires_setup` or `browser_consent_required`, choose one
-explicit preparation flow. A standalone consumer browser cannot bind through
+explicit preparation flow. For the user's running Chrome, Edge or Brave the
+refusal's `detail.next_call` is the exact `browser_prepare` call to make next
+(`pid`, `window_id`, `session`, `strategy:{"kind":"existing_profile"}`). It is
+the driver's own setup step, not a question for the user: make the call, and it
+attaches or refuses with nothing changed and says why. Do not fall back to
+desktop-target pointer tools for the page; they move the user's real pointer,
+and over a background window they refuse. A standalone consumer browser cannot bind through
 a DevTools listener merely because the listener belongs to that process.
 
 ### Driver-owned isolated profile
@@ -153,6 +159,18 @@ or terminates an existing personal profile. The result returns a
 `prepared_pid`; list that process's windows and bind the new `(pid,
 window_id)`.
 
+The result's optional `lifecycle` object describes how long the browser
+process lives: `owner` is `session`, `idle_expires_in_seconds` is how long the
+session may stay idle after this call before it and the browser end,
+`process_ends_with_session` is `true`, and
+`profile_persists_after_session` is `true` only for `isolated_named`. The
+value is advisory, not a lease. `get_session` reports the remaining time later
+but does not keep the browser alive, and explicit `end_session`, disconnect,
+revocation, or shutdown ends the browser earlier. A named profile keeps its
+files, not the process or its open pages. Attachments to an existing profile
+or endpoint the driver did not launch, and sessions already ending, have no
+`lifecycle`.
+
 ### Existing profile
 
 Attaching to an authenticated profile requires explicit trusted launch or host
@@ -199,6 +217,31 @@ transition on that same control. Unsupported appearance, scale, zoom,
 window-size, or toolbar geometry refuses without a click; the fallback does not
 authorize generic pixel interaction.
 
+On macOS this attachment cannot stay in the background. Chrome brings itself
+to the front to show its "Allow remote debugging?" prompt for every new
+DevTools connection, and turning remote debugging on needs Chrome in front.
+Chrome does not prompt again for tabs or targets reached over a connection it
+already allowed, so the driver keeps one approved connection per running
+Chrome and every session for that Chrome shares it: a second session, or a new
+session after the previous one ended, attaches without another prompt. Each
+session still needs its own `browser_prepare` approval from the driver, and
+only sees the targets it bound. The shared connection closes after 30 minutes
+without a session, 8 hours after the prompt that opened it, when the daemon
+restarts, on `cua-driver revoke --all`, or when the driver turns remote
+debugging back off; the next session after that prompts once again.
+When the Chrome window is on another Space than the user's, the attach runs in
+the background: the driver turns remote debugging on without bringing Chrome
+forward, and reverts Chrome's own brief activations (its consent window opens
+on Chrome's Space, out of the user's sight) within milliseconds, giving the
+user's window front and key status back. On the user's Space, while another
+app is in front, `browser_prepare` with `strategy.kind:"existing_profile"`
+refuses with `background_unavailable` before it opens a tab or connects. Keep
+or put Chrome on another Space, or pass `delivery_mode:"foreground"` only when
+nobody is using the screen or the user agreed to Chrome coming forward; the
+driver then brings the previous app back and reports
+`side_effects.restored_frontmost_app`. If the user is working in another app,
+read the Chrome window with `get_window_state` instead.
+
 Chrome 144 and later can expose its agent auto-connect bridge from the running
 profile. After approval, Cua reads the exact port and browser WebSocket path
 from that process's `DevToolsActivePort` file, cross-checks the loopback socket
@@ -348,11 +391,12 @@ browser_click
 Before dispatch, the driver refreshes the element box and hit-tests the point.
 It refuses stale, covered, or ambiguous targets.
 
-Standalone Chromium on macOS and Linux can activate its native window when
-trusted CDP pointer input is used. CUA Driver detects that limitation and
-returns `browser_input_trust_unavailable` before dispatch instead of claiming
-background delivery. Windows Chrome and Edge have validated trusted
-background delivery.
+Standalone Chromium on Linux can activate its native window when trusted CDP
+pointer input is used. CUA Driver detects that limitation and returns
+`browser_input_trust_unavailable` before dispatch instead of claiming
+background delivery. Chrome and Edge on Windows, and Chrome on macOS, deliver
+trusted input in the background, including to an inactive (hidden) tab,
+without activating or raising the browser window.
 
 When the application semantics allow a synthetic JavaScript click, request it
 explicitly with a current ref:
@@ -363,8 +407,11 @@ browser_click
     "input_route":"dom_event","session":"browser-run-1"}'
 ```
 
-`dom_event` calls the page element's click behavior without pretending that a
-trusted pointer event occurred. It requires a ref and is the full-background
+`dom_event` replays a primary-button click as synthetic DOM events at the
+element's center: pointer and mouse over, move, down, up, then `click`. Apps
+that open rows or menus from pointer or mouse down/up, as many React tables
+do, respond to it; it does not pretend that a trusted pointer event occurred.
+Controls that check `event.isTrusted` still need the trusted route. It requires a ref and is the full-background
 alternative where supported. Dispatch is not proof that the control activated:
 trust-gated controls can ignore synthetic events, so refresh page state and
 verify the expected postcondition. Never silently change trust class or

package/dist/builtin/subagents/skills/cua-driver/EMBEDDING.md

@@ -204,8 +204,13 @@ daemon child.
 
 After an input action, the driver watches the window list for a short time so
 it can report a menu, dialog, or new window that the action opened. On macOS,
-that watch lasts up to 1000 ms for an action that opens nothing, which makes it
-the largest part of a background click's latency. A host that already observes
+the watch lasts up to 1000 ms. The action's result waits for at most the first
+300 ms of it; when nothing has changed by then, the result returns and the rest
+of the watch runs detached, still holding the focus-steal lease. A window that
+opens during that remainder is reported on the next action's result as
+`After the previous action returned, it opened new window(s): …`. The next
+action, or any activation the driver performs, ends the detached remainder
+first. On Linux X11 the result waits for the whole watch. A host that already observes
 its target continuously can shorten it through two variables set at trusted
 launch, in the environment of the `serve --embedded` child (or of the host
 process when you use the same-process runtime). `EmbeddedCuaDriverHost` starts

package/dist/builtin/subagents/skills/cua-driver/LINUX.md

@@ -77,7 +77,7 @@ sentence naming the call that targets each one
 (`get_window_state(pid, window_id=<that id>)`). When one overlaps the window
 the screenshot is taken from the screen (`screenshot_composited:true`) so the
 menu or dialog is visible; the window's own drawable never shows them. The
-payload states its frame (`coordinate_frame:"window"`, `frame_note`): `x`/`y`
+payload states its frame (`coordinate_frame:"window"`, plus `frame_note` with `verbose:true`): `x`/`y`
 of the pointer tools are pixels of THIS screenshot. Closed menus are listed
 with a `description` ("closed menu with N items…") and are not walked;
 click the menu (a real press) and read the popup by its window_id.
@@ -212,6 +212,12 @@ doctor` now probes `org.a11y.Bus` for real (not just "is there a bus?")
    daemon as root against a user session is the Linux analogue of the Windows
    "Session 0" isolation problem.
 
+`get_window_state` returns one compact markdown tree capped at 250 actionable
+nodes by default (`full_output:true` restores 5 000 nodes and both forms), and
+`since:<snapshot_id>` returns only added/changed/removed rows. The focused
+element is not reported on Linux yet, so an unchanged read says only
+`no change since …`.
+
 An empty AT-SPI walk is now surfaced honestly: `get_window_state` sets
 `degraded: true` + a `degraded_reason` (instead of a bare `elements: []`) so a
 caller can tell "this window genuinely has no controls" apart from "the a11y