@bastani/atomic 0.9.43 → 0.9.44-alpha.2

package/dist/builtin/intercom/live-route-refusal.ts

@@ -67,3 +67,23 @@ export class IntercomLiveRouteRefusedError extends Error {
 		this.transient = isTransientLiveWorkflowStageRouteRefusal(code);
 	}
 }
+
+/**
+ * How long a starting stage keeps waiting out an `owner_missing` refusal. The run's owner
+ * registers its route over its own broker connection, which may still be connecting, backing
+ * off (up to 30 s) or waiting out 10 s connect and acknowledgement timeouts when the stage
+ * starts, so a few quick retries would turn ordinary registration latency into a failed stage
+ * (#3904). Past this bound the refusal surfaces as before.
+ */
+export const LIVE_ROUTE_OWNER_WAIT_MS = 120_000;
+const LIVE_ROUTE_OWNER_RETRY_FIRST_MS = 250;
+const LIVE_ROUTE_OWNER_RETRY_MAX_MS = 2_000;
+
+/** Delay before the next registration attempt while the owner is missing: doubling, capped at 2 s. */
+export function liveRouteOwnerRetryDelayMs(attempt: number): number {
+	return Math.min(LIVE_ROUTE_OWNER_RETRY_FIRST_MS * 2 ** attempt, LIVE_ROUTE_OWNER_RETRY_MAX_MS);
+}
+
+export function isOwnerMissingRefusal(error: unknown): boolean {
+	return error instanceof IntercomLiveRouteRefusedError && error.code === "owner_missing";
+}

package/dist/builtin/intercom/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@bastani/intercom",
-  "version": "0.9.43",
+  "version": "0.9.44-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/skills/intercom/SKILL.md

@@ -247,12 +247,15 @@ In Atomic workflows, each invocation has its own Intercom group, and parallel st
 
 ### Pattern 8: Peer Coordination Between Subagents and Workflow Stages
 
-Communication inside a delegation is not only vertical. Children launched in one parallel set (or one explicit `group`) share an Intercom group, and workflow stages share their invocation group `workflow:<rootRunId>`; delegated subagents inside a stage inherit it. Any of them can list live siblings and message them directly. `contact_supervisor` is reserved for the supervisor; peer traffic uses ordinary `intercom`.
+Peer-to-peer (swarm) is the default topology inside a delegation. There are no limits on communication between agents; it is encouraged whenever you need to. The supervisor is not a message relay: relaying adds latency, loses detail, and fills the supervisor's context, so siblings exchange evidence directly and self-organize. Children launched in one parallel set (or one explicit `group`) share an Intercom group, and workflow stages share their invocation group `workflow:<rootRunId>`; delegated subagents inside a stage inherit it. Any of them can list live siblings and message them directly. `contact_supervisor` is reserved for the supervisor; peer traffic uses ordinary `intercom`.
 
 ```typescript
 // Any child or stage: discover who is live in your group
 intercom({ action: "list" })
 
+// Broadcast: share a finding with every live sibling in the workflow
+intercom({ action: "send", to: "workflow:<rootRunId>/**", message: "Root cause confirmed: cache key omits tenant id (src/cache.ts:52). Adjust your angle." })
+
 // Connect: pass what you found to the sibling who needs it
 intercom({ action: "send", to: "codebase-analyzer-2", message: "Null handling lives in src/auth/session.ts:40-118 and src/auth/refresh.ts:12-60. Start there." })
 
@@ -266,14 +269,16 @@ intercom({ action: "ask", to: "debugger-1", message: "What exact command and env
 intercom({ action: "ask", to: "reviewer-2", message: "You called the retry loop unbounded. client.ts:88 caps attempts at 5 — which path bypasses it?" })
 ```
 
-Rules that keep peer exchange useful:
+How a swarm works:
 
-- Peers do not coordinate spontaneously. The launcher's prompt should name the peers (or how to discover them with `list`) and what they are expected to exchange.
-- Bound the exchange: one evidence round for reviewers, one ownership claim per shared step, one ask per fact you need. Then return your own complete result.
-- Decide on evidence, not deference. A peer's approval, rejection, or claim is input to inspect, not a verdict to copy.
-- Scope, product, architecture, and acceptance decisions stay with the supervisor (`contact_supervisor`) or a workflow gate.
+- Coordinate proactively. Discover peers with `list` as soon as you start and again whenever new siblings may have joined, without waiting for the launcher to name them.
+- Broadcast findings, claim files or expensive steps, hand work along a chain, ask and answer each other, and debate disagreements for as long as it is useful.
+- Decide on evidence, not deference. A peer's approval, rejection, or claim is input to inspect, not a verdict to copy, and each agent still returns its own result.
+- `contact_supervisor` is for supervisor decisions; explicit user approval gates and authorization for destructive or external actions still apply.
 - Inside a workflow, `send` to a known pending sibling queues until it starts, and `ask` to a completed sibling that retains a valid conversation reopens it for a post-mortem turn. Named stage subgroups isolate their members from sibling subgroups.
+- Choose `delivery` per `send`/`ask` by urgency. The default `"steer"` arrives after the recipient's current tool calls finish and never cancels its work. Use `"interrupt"` when it must stop now (an urgent correction or a stop order), and `"followUp"` when the message can wait until it finishes (low priority, "after you're done").
 - Peer asks and one blocking supervisor request may wait concurrently in the same child; mutual asks work when both sides process inbound work.
+- Scale with the task. For very complex work or requested heavy parallelism, hundreds or thousands of agents self-organize into teams (named groups, per-stage subagent sets, child workflows) and coordinate peer-to-peer like an organization. Groups have no member limit; team members reach their lead with `contact_supervisor`, and leads talk to each other in their shared group.
 
 ## Key Differences
 

package/dist/builtin/intercom/types.ts

@@ -115,11 +115,19 @@ export interface BrokerStatusReport {
 	multiNode: BrokerMultiNodeStatus;
 }
 
+export type IntercomDeliveryMode = "steer" | "followUp" | "interrupt";
+
 export interface Message {
   id: string;
   timestamp: number;
   replyTo?: string;
   expectsReply?: boolean;
+  /**
+   * How a busy recipient receives this message. `steer` (default when absent) queues it until the current turn's tool
+   * calls finish, never cancelling in-flight work. `followUp` waits until the recipient's agent finishes and stops.
+   * `interrupt` cancels the current model call or cancellable tool call and handles the message next.
+   */
+  delivery?: IntercomDeliveryMode;
   /** Correlated delivery refusal: settles a waiting ask, otherwise surfaces as send feedback. */
   replyError?: string;
   source?: {
@@ -221,6 +229,12 @@ export type ClientMessage =
 		parent?: WorkflowRunParentAnnouncement;
 		/** Interrupted run queued by its restarted owner before resume; yields to the process that resumes it (#3760). */
 		dormant?: true;
+		/**
+		 * #3906: the connection carries the routes of many runs, so a refusal of this one is answered with
+		 * `pending_stage_route_refused` and leaves the connection open. Honoured only with a `requestId`, and sent only to
+		 * a broker that advertised `refusesPendingStageRoutesInPlace`; an older broker ignores it and ends the connection.
+		 */
+		refusalKeepsConnection?: true;
 	}
   | {
       type: "register_live_workflow_stage_route";
@@ -254,6 +268,9 @@ export type ClientMessage =
 	/** Allowed before `register`: shut the broker down; its sessions reconnect to a new broker. */
 	| { type: "shutdown"; requestId: string };
 
+/** Why the broker refused a pending-stage route registration (#3906). Authorization decides these, not the client. */
+export type PendingStageRouteRefusalCode = "not_authorized" | "invalid_stage_roster" | "invalid_possible_stage_roster";
+
 export type BrokerMessage =
 	| { type: "health"; requestId: string; instanceId: string }
 	| {
@@ -264,10 +281,12 @@ export type BrokerMessage =
 			acknowledgesReceipt?: true;
 			/** This broker acknowledges a `register_pending_stage_route` that carries a `requestId`; absent on older brokers. */
 			acknowledgesPendingStageRoutes?: true;
+			/** #3906: this broker honours `refusalKeepsConnection`; absent on older brokers, which end the connection. */
+			refusesPendingStageRoutesInPlace?: true;
 			/** This broker answers `broker_status`; absent on older brokers, which drop a client that sends it. */
 			brokerStatus?: true;
 	  }
-  | { type: "registration_failed"; reason: string; code?: LiveWorkflowStageRouteRefusalCode }
+  | { type: "registration_failed"; reason: string; code?: LiveWorkflowStageRouteRefusalCode; requestId?: string }
   | { type: "question_target"; messageId: string; attemptId: string; sessionId: string }
  | { type: "sessions"; requestId: string; sessions: SessionInfo[]; workflowStages?: WorkflowStageRosterEntry[]; workflowFutureStages?: WorkflowFutureStageRosterEntry[]; restricted?: true }
 	| { type: "groups"; requestId: string; groups: GroupSummary[] }
@@ -288,6 +307,14 @@ export type BrokerMessage =
 	  }
   | { type: "live_workflow_stage_route_registered"; requestId: string }
 	| { type: "pending_stage_route_registered"; requestId: string }
+	/** #3906: the registration `requestId` of run `runId` was refused; the connection and its other routes are kept. */
+	| {
+			type: "pending_stage_route_refused";
+			requestId: string;
+			runId: string;
+			code: PendingStageRouteRefusalCode;
+			reason: 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 }

package/dist/builtin/mcp/CHANGELOG.md

@@ -7,6 +7,13 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 ## [Unreleased]
 
+## [0.9.44-alpha.1] - 2026-10-24
+
+### Fixed
+
+- MCP sign-in now accepts only `http:` and `https:` authorization endpoints and other OAuth metadata URLs. Before, a malicious MCP server could supply a `file:` or custom protocol authorization endpoint (for example `search-ms:`), which the platform URL handler would launch on sign-in ([pi 9ffd27cf](https://github.com/earendil-works/pi/commit/9ffd27cfaaeed5c1ecf9369f393c3222975729b4))
+- The excerpt of an HTTP error body in Streamable HTTP errors no longer keeps the whole response body alive ([pi #9265](https://github.com/earendil-works/pi/issues/9265))
+
 ## [0.9.35] - 2026-10-13
 
 ### Fixed

package/dist/builtin/mcp/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@bastani/mcp",
-  "version": "0.9.43",
+  "version": "0.9.44-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,15 @@
 
 ## [Unreleased]
 
+## [0.9.44-alpha.1] - 2026-10-24
+
+### Changed
+
+- **Security policy change:** on macOS, the agent now approves Cua Driver's own Accessibility and Screen Recording permission prompts itself by default, without asking, by clicking them through the host's VNC or Screen Sharing server when credentials for it are available (for example `CUA_VNC_SERVER` and `CUA_VNC_PASSWORD`). It reports each approval and when it happened, never approves any other permission or another app's dialog, and types a password only when you supplied one. Set `ATOMIC_CUA_AUTO_APPROVE=0` to turn this off and have the agent ask you to grant the permissions, as before.
+- Updated the bundled Cua Driver skill to upstream `cua-driver-rs-v0.38.0`. Refusals, `unverifiable` actions and `suspected_noop` results now come with a `hint` and a safe `next_call` to try, and three single actions in a row suggest batching with `run_steps`. Steps inside `run_steps` and `run_script` skip most of the cursor glide and window watch on macOS. The macOS guide adds installing and updating the driver and granting its permissions with an MDM profile on managed Macs. It also covers `invoke_menu` refusing unless the requested window is key, background `<select>` menus in Chrome and Electron via `set_value`, Electron drags, and handing a URL to a specific Windows browser with `additional_arguments`.
+- Updated the bundled Herdr skill to upstream `v0.9.5`. It can now control agents and panes on a saved SSH machine with `herdr --machine <label-or-id>`, and it explains that an agent suspended with Ctrl+Z keeps its identity, that Antigravity and Grok can look idle while background work continues, that `pane run` only acknowledges admission (and rejects over-long lines on macOS), and that CLI closes skip the TUI's last-pane confirmation. The explicit-request trigger and the `HERDR_ENV=1` requirement are unchanged.
+- Subagents now default to peer-to-peer (swarm) coordination with no limits on communication between agents: children discover siblings with `intercom list` and broadcast, debate, claim, hand off, and ask each other directly instead of relaying through the supervisor. Explicit user approval and authorization gates still apply. Swarms scale with the task: for very complex work or requested heavy parallelism, hundreds or thousands of agents self-organize into teams, and the subagents guide documents the settings that bound swarm size. The `parallel.maxTasks`, `parallel.concurrency` and `parallel.runningCapacity` defaults rise from 50, 3 and 4 to 1000, so one parent can run up to 1000 children at once without configuration; set them lower in `~/.atomic/agent/extensions/subagent/config.json` to throttle, or higher for larger swarms.
+
 ## [0.9.41] - 2026-10-22
 
 ### Added

package/dist/builtin/subagents/README.md

@@ -234,7 +234,7 @@ The child can use one dedicated coordination tool:
 
 Child-side routine completion handoffs are still not expected. In parallel runs, blocking `contact_supervisor` decisions/interviews and parent-targeted `intercom.ask` wait only in the requesting child. The supervisor replies through Intercom to the exact question; the same child continues with its original context and run identity. Sends and progress updates return without a reply.
 
-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.
+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. Peer-to-peer (swarm) exchange is the default, and the supervisor is not a message relay. There are no limits on communication between agents; it is encouraged whenever you need to. Children coordinate spontaneously and each still returns its own result. For very complex work or requested heavy parallelism, swarms scale to hundreds or thousands of agents organized into teams; see [Scaling a swarm](../coding-agent/docs/subagents.md#scaling-a-swarm) for the limits. 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 `pause`/`quit`, explicit batch cancellation, and owner closure remain separate controls.
 
@@ -542,7 +542,7 @@ Agent definitions are not loaded into context by default. Management actions let
 | `skill` | `string \| string[] \| false` | agent default | Override skills or disable all. |
 | `model` | string | agent default | Override model. |
 | `tasks` | array | - | Top-level parallel tasks. Supports `agent`, `task`, `cwd`, `count`, `output`, `outputMode`, `reads`, `progress`, `skill`, and `model`. |
-| `concurrency` | number | config or `3` | Top-level parallel concurrency. |
+| `concurrency` | number | config or `1000` | Top-level parallel concurrency. |
 | `worktree` | boolean | false | Create isolated git worktrees for parallel tasks. |
 | `context` | `fresh \| fork` | agent default or `fresh` | `fork` creates real branched sessions from the parent leaf. Packaged `worker` defaults to `fork`; every other builtin runs fresh. |
 | `agentScope` | `user \| project \| both` | `both` | Agent discovery scope. Project wins on collisions. |
@@ -607,16 +607,16 @@ Subagent configuration controls discovery, parallel limits, session storage, con
 ```json
 {
   "parallel": {
-    "maxTasks": 100,
-    "concurrency": 100,
-    "runningCapacity": 100
+    "maxTasks": 2000,
+    "concurrency": 2000,
+    "runningCapacity": 2000
   }
 }
 ```
 
-- `maxTasks` defaults to `50` and limits tasks per parallel set after `count` expansion. There is no hard upper cap.
-- `concurrency` defaults to `3` and limits how many children are dispatched at once. Per-call `concurrency` takes precedence.
-- `runningCapacity` defaults to `4` and limits simultaneously running child turns per parent. To run N children at once, raise both `concurrency` and `runningCapacity` to N, and set `maxTasks` to at least N.
+- `maxTasks` defaults to `1000` and limits tasks per parallel set after `count` expansion. There is no hard upper cap.
+- `concurrency` defaults to `1000` and limits how many children are dispatched at once. Per-call `concurrency` takes precedence.
+- `runningCapacity` defaults to `1000` and limits simultaneously running child turns per parent. To run more than 1000 children at once, raise `concurrency`, `runningCapacity` and `maxTasks` together.
 
 Running capacity is selected when a parent's first child is created. Restart Atomic after changing this setting to apply the new capacity.
 

package/dist/builtin/subagents/agents/worker.md

@@ -21,7 +21,7 @@ Treat an approved handoff or execution plan as the contract. Inspect inherited c
 
 Do not silently make a new product, architecture, or scope decision. When implementation reveals an unapproved decision required to continue safely, use the live coordination route supplied at runtime. Use `contact_supervisor` with `reason: "need_decision"`; a claimed request ends this child and gives the supervisor a fresh-subagent handoff, so do not wait for a reply in this run. Use `reason: "progress_update"` only for a concise, non-blocking update when helpful or explicitly requested. Fall back to `intercom` for the supervisor only when `contact_supervisor` is unavailable.
 
-Peers are a different route. Sibling agents launched with you share your Intercom group; `intercom({ action: "list" })` shows them. Use ordinary `intercom` `send`/`ask` with a peer to divide file ownership, serialize a shared suite or build, pass on a reproduction or file location, or challenge a finding with evidence, when the task names the peers or the information clearly lives with a sibling. Peer exchanges stay bounded and never settle scope, product, or architecture questions.
+Peers are a different route. Sibling agents launched with you share your Intercom group; `intercom({ action: "list" })` shows them. There are no limits on communication between agents; it is encouraged whenever you need to. Use ordinary `intercom` `send`/`ask` with peers proactively to divide file ownership, serialize a shared suite or build, pass on a reproduction or file location, or challenge a finding with evidence. Peer exchanges never settle scope, product, or architecture questions.
 
 Do not end with a question requiring the supervisor to choose before work can continue. Do not send routine completion handoffs; return the normal task result when coordination is unnecessary. If you sent a progress update through `contact_supervisor`, keep it short and still provide the full structured result.
 

package/dist/builtin/subagents/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@bastani/subagents",
-  "version": "0.9.43",
+  "version": "0.9.44-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.39.1
+    github-ref: refs/tags/v0.39.2
     github-repo: https://github.com/vercel-labs/agent-browser
     github-tree-sha: 82def67855a0d2aad7794207951820fa5422fdb0
 name: agent-browser

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

@@ -262,6 +262,25 @@ Measured on macOS with Calculator in the background and Terminal frontmost, a
 background AX click took 1153 ms with the default, 325 ms with `200`, and 78 ms
 with `0`.
 
+### Steps inside `run_steps` and `run_script` (macOS)
+
+Two waits make up most of a macOS action's latency: the agent cursor's glide to
+the target (600 ms or more with the default `steady` timing) and the first 300 ms
+of the window watch above. A call that is one step of a `run_steps` batch or a
+`run_script` program is followed at once by another step, so the driver shortens
+both for it: the step waits at most 120 ms for the cursor to arrive and 100 ms
+for a window change. The cursor keeps gliding and the watch keeps running
+detached, as above, so a window that opens late is still reported on the next
+action's result. The last step of a `run_steps` batch, and every direct call,
+keep the full waits, so the batch's final result still reports what it left
+open. A script has no last step the driver can know in advance; read the window
+with `getState()` or `waitFor()` after the action that opens something.
+
+An embedding host that wants every step to play the full glide and watch, for
+example to record a demo, sets `CUA_DRIVER_BATCH_PACING=full` in the same
+environment as the variables above. Any other value, or none, applies the
+shortened waits. No tool argument can change it.
+
 ## Pacing synthesized keystrokes (macOS)
 
 The macOS keyboard adapter waits a fixed gap between each key down and up and
@@ -294,7 +313,7 @@ and about 980 ms at `2`. All ten read-backs (five per value) matched exactly.
 | --------------------------------------------- | ----------------------------- | -------------------------------------- |
 | Responsibility disclaim re-exec               | ON (owns its TCC identity)    | OFF (stays in the host's chain)        |
 | Tool execution process                        | `serve` daemon                | host-spawned `serve --embedded` daemon |
-| Daemon auto-relaunch via `open -a CuaDriver`  | Yes, when installed           | Never (would leave the host's chain)   |
+| Daemon auto-relaunch of the installed app     | Yes, when installed           | Never (would leave the host's chain)   |
 | TCC identity                                  | `com.trycua.driver`           | the host app                           |
 | Permission prompts / startup gate             | May prompt once               | **Never prompts**                      |
 | Settings → Privacy & Security entries         | CuaDriver                     | your app only                          |
@@ -315,7 +334,7 @@ would treat it as its own responsible process: your user would get a _second_ pr
 attributed to the driver binary, a second Settings entry, and capture/AX
 would fail until that second grant. That is the exact experience embedding exists
 to eliminate. Embedded mode short-circuits the disclaim re-exec
-(`responsibility.rs`) and the `open -a CuaDriver` daemon relaunch. MCP is
+(`responsibility.rs`) and the installed-app daemon relaunch. MCP is
 always a proxy, so the embedded daemon remains the single process that checks
 TCC and executes tools.
 

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

@@ -360,10 +360,10 @@ uninstrumented module hash are unchanged at
 `1133a06e4f205cf80188a7ac9e41102f37611fea`. The proof covers recorded actions
 and observation intervals, not every application operation or release package.
 Portable tests and historical experiments do not replace complete native
-harness acceptance. Compatible release artifacts and final Fleet image
+harness acceptance. Compatible release artifacts and final image
 packaging and lifecycle validation require separate evidence. Physical Omarchy
 parity requires separate acceptance; it is not a gate for publishing a validated
-Fleet image.
+image.
 
 ## Quick triage