@bastani/atomic 0.9.45 → 0.9.46-alpha.1

package/CHANGELOG.md

@@ -2,6 +2,40 @@
 
 ## [Unreleased]
 
+## [0.9.46-alpha.1] - 2026-10-27
+
+Stages on local workers can now be watched, steered, paused and answered live; large pooled workflows stay responsive and recover cleanly from rate limits, worker crashes and resumes; and GPT-6.1 Terra is available.
+
+- **Live chat for pooled stages:** opening a running stage on a local worker shows its live transcript. Enter steers, Ctrl+F queues a follow-up, `/workflow pause <run> <stage>` pauses just that stage, and `ctx.ui` and `ask_user_question` prompts are answered from the stage chat. When a worker dies, the chat reconnects to its replacement, a pending prompt is asked again, and every pending message is delivered exactly once.
+- **Responsive at scale:** a 150-worker fan-out no longer stalls the root while children start or finish, even with the graph and a stage chat open. One child that keeps losing its worker now fails alone instead of taking its siblings with it.
+- **Rate limits handled the way providers ask:** `Retry-After` is honored on every provider path, including Google and Bedrock. A quota-exhausted model moves straight to the next fallback, a chain where every model is throttled waits for the earliest cooldown, and a limit one local worker meets now holds back the other workers and the root too.
+- **Failures classified by what happened:** a child workflow's failure no longer depends on its name, and SDK callers get the classification in `RunResult.failure`.
+- **Pools that survive crashes and resumes:** resuming a quit root no longer fails in-flight children, journal writers are served in order instead of timing out, and workflow runs survive a deleted `jiti` cache.
+- **New models:** GPT-6.1 Terra on OpenAI, Azure and Codex, with a Fast tier on the OpenAI API, and correct reasoning-effort levels for GPT-6 models on Bedrock.
+- **Hardening from upstream pi:** OAuth logins accept only trusted URLs, terminal titles and the login dialog strip control characters, and the CLI auth file is written with mode 0600.
+
+### Added
+
+- GPT-6.1 Terra is available as `openai/gpt-6.1-terra`, `openai-codex/gpt-6.1-terra` and `azure/gpt-6.1-terra`, with a derived `openai/gpt-6.1-terra-fast` choice. It supports `off` through `max` (not `minimal`), and `openai-codex/gpt-6.1-terra` has a 500K context window ([pi 363ad78b](https://github.com/earendil-works/pi/commit/363ad78bf0625e1dfbe848429782f5e07bb1584e))
+- `@bastani/atomic` exports `observeProviderRateLimits()`, `providerRateLimitObservations()` and `applyProviderRateLimitObservation()` with the `ProviderRateLimitObservation` type, so another process on the same host can apply the provider and model cooldowns and quota-exhausted marks this process recorded. An applied limit only ever extends the matching provider or model limit and counts no failure ([#4023](https://github.com/bastani-inc/atomic/issues/4023))
+
+### Fixed
+
+- The `Full output:` path of a truncated shell result, both a foreground command and a `wait` on a background task, now sits on its own line and links to the file. Before, it followed its label on the same line, so word wrap could split a path containing spaces (such as `C:\Users\Jane Doe\AppData\Local\Temp\…`) partway through and the copied path no longer worked. A path wider than the terminal still wraps, but its link still opens the whole file ([#3828](https://github.com/bastani-inc/atomic/issues/3828))
+- A workflow child run whose stage had launched a background subagent no longer fails with `This extension ctx is stale after session replacement or reload` after the stage's model fallback replaces its session. The subagent's auto-routed model check, which the child also uses to pick its next fallback model, no longer reads the replaced session. The child now moves on to its next fallback model, and the run keeps the stage's real error, such as a rate limit. A subagent that waited for a free slot and starts after the replacement no longer fails to launch: it takes its settings from the replacement session, or from the launching session's last state when that session closed with no replacement ([#3981](https://github.com/bastani-inc/atomic/issues/3981))
+- When the model that picks `auto` models (the router) answers with an HTTP 429 or an exhausted quota (402), the routing error now keeps that status, a rate-limit or quota code and the server's `Retry-After` hint. Before, it reported only `provider request failed`, so a workflow stage whose routing hit a rate limit was blocked as a provider outage. Now it is blocked as a rate limit or exhausted quota. The provider's error text is still never kept ([#4031](https://github.com/bastani-inc/atomic/issues/4031))
+- Provider cooldowns now honor `Retry-After` on every provider path, including Anthropic-format models, instead of guessing an exponential backoff. HTTP 402 and quota-exhaustion codes (`insufficient_quota`, `quota_exceeded`, `usage_limit*`) are classified as the new `quota_exhausted` failure kind: the account counts as unavailable until its reset, and the turn moves to a configured fallback model instead of retrying the same model. When a rate-limit response names the model that hit the limit, only that model cools down; other models on the provider stay usable. Limits that do not name a model still cool the whole provider ([#3984](https://github.com/bastani-inc/atomic/issues/3984))
+- A workflow stage whose model fallback replaced its session no longer fails the replacement's prompt with `Agent is already processing. Specify streamingBehavior…` when an Intercom message reaches the stage during the swap. Like a fresh stage, the replacement now holds turn-starting messages as context for the stage prompt's turn ([#3982](https://github.com/bastani-inc/atomic/issues/3982))
+- Fixed a `.ts` storage adapter that serves both `sessions.storage` and `workflows.journal` failing to import `@bastani/atomic/workflows` when sessions loaded first; the journal now gets the running Atomic's workflows module ([#3973](https://github.com/bastani-inc/atomic/issues/3973))
+- ES module and TypeScript files a storage adapter imports by relative path now get the running Atomic's `@bastani/atomic/workflows`, `@bastani/atomic/storage`, and `@bastani/atomic`, as the adapter's entry file does. Before, a `.mjs` file or a `.js` file in a `"type": "module"` adapter package could resolve these imports from `node_modules` instead, so errors such as `StaleLeaseError` thrown from it failed Atomic's `instanceof` checks. CommonJS files other than the entry file still resolve these imports from `node_modules` ([#3972](https://github.com/bastani-inc/atomic/issues/3972))
+- Fixed subagents launched with `context: "fork"` finishing instantly as "completed" with the parent's last message as their output. A forked child's history now stops before the parent's in-flight turn that is launching it, so providers that sign thinking no longer reject the child's first request as a modified turn. A child's output now comes only from messages it produced itself, and a child whose own turns all failed, or that ran none, is reported as failed with the provider's error instead of completing with inherited text. A child that completed a turn without final text, such as a tool-only child, still completes ([#3987](https://github.com/bastani-inc/atomic/issues/3987))
+- GitHub Copilot offers fewer models that fail on the first request with `model_not_available_for_integrator`: models enabled during `/login` are offered only if the model list re-read afterwards marks them usable, and an older login without a stored model list re-reads it on the next networked model refresh (until then, including offline, it keeps offering the catalog). Models you define for `github-copilot` in `models.json` stay offered. If Copilot still rejects a model this way, a fallback chain moves on to its next model, and the error reads "<model> isn't available to Atomic's GitHub Copilot integration; pick another model or run /login to refresh the model list" followed by the raw error ([#3998](https://github.com/bastani-inc/atomic/issues/3998))
+- `tool_search` and codemode `searchTools()` rank a tool first when the query is its name, either the full name or the part after a `__` separator (`thread_read` for `mcp__app__thread_read`). Before, a shorter description that shared the name's words could rank above it ([pi #11331](https://github.com/earendil-works/pi/issues/11331))
+- Writers to one SQLite journal in different processes now take its write lock in turn, so a busy process that commits and begins again can no longer starve the others, and a transaction waiting for the lock fails only when the lock is held for the whole lock wait with no other connection committing, instead of after 30 s however busy the lock was with real work. Large local worker pools no longer lose children to `database is locked … gave up after waiting 30000 ms for the write lock` under contention ([#3978](https://github.com/bastani-inc/atomic/issues/3978))
+- The login dialog opens only web (`http:`/`https:`) sign-in URLs, and no longer prints control characters from sign-in, device-code or info URLs, which could end a terminal hyperlink and send escape sequences to the terminal. The terminal title likewise replaces control characters in session names and extension titles ([pi 89c921d8](https://github.com/earendil-works/pi/commit/89c921d8b56b59e768b26e7f48b6832978119310))
+- A Bedrock `ServiceQuotaExceededException` and a Google error body reporting a per-day quota violation now count as an exhausted quota, so model fallback moves straight to the next model instead of retrying the same one, and a throttled Bedrock request (`ThrottlingException`, shown as `Throttling error: …`) now counts as a rate limit, so its `Retry-After` cools the model down for other requests. The classifier also reads the error code a provider failure diagnostic records.
+- `tool_search` and codemode `searchTools()` now find a tool whose name is made only of stop words (for example `is`) when the query names it; other stop-word-only queries still return nothing.
+
 ## [0.9.45] - 2026-10-25
 
 Custom storage adapters now plug into workflow journals as first-class citizens, and large local worker pools start reliably on busy machines.

package/dist/builtin/intercom/CHANGELOG.md

@@ -4,6 +4,17 @@ All notable changes to the `pi-intercom` extension will be documented in this fi
 
 ## [Unreleased]
 
+## [0.9.46-alpha.1] - 2026-10-27
+
+### Fixed
+
+- The session that launched a workflow run can now send to that run's stages by exact path (`workflow:<rootRunId>/<stage>`) and by pattern (`workflow:<rootRunId>/**`), and sees them in `intercom list`, without joining the run's invocation group. Before, the send was refused with `Target workflow run is in a different intercom group`, because the run's route is registered on a separate connection and the broker could not tell that the sender had launched the run. The launching session now proves this with a secret that only its own process holds, never the run's stages. Its group memberships do not change, so the run's stages still cannot message it. A session that joins `workflow:<rootRunId>` keeps the same authority, and every other session is still refused, now with an error that names the group to join ([#4006](https://github.com/bastani-inc/atomic/issues/4006))
+- A send to a recipient that is still saving the message, such as a stage on a local worker whose journal commit waits behind other writers, now waits for that save instead of reporting after 8 s that the outcome is uncertain. The recipient reports progress while it saves; a recipient that dies stops reporting, so its sender still hears the outcome is uncertain, and no save holds a sender longer than 2 minutes. This also holds when the recipient is connected through another broker node ([#3983](https://github.com/bastani-inc/atomic/issues/3983))
+- A connection to the Intercom broker that the operating system refuses because the broker socket's listen backlog is full, as happens when a large pooled fan-out starts many sessions at once, is now retried briefly instead of failing that session's Intercom ([#3904](https://github.com/bastani-inc/atomic/issues/3904))
+- A session that launched a workflow run, or that joined `workflow:<rootRunId>` from another group, now receives the failure notice when a message it queued to one of the run's pending stages becomes undeliverable (for example because the stage was skipped). The notice used to reach only senders registered in the run's own group, so these senders never learned their message was dropped. The notice still goes only to the session that sent the message ([#4006](https://github.com/bastani-inc/atomic/issues/4006))
+- A send to a session on another broker node that quits cleanly while the send is being routed is now queued for that session and delivered when it reconnects, as a send made after the quit is. Before, when the sender's broker still saw the session as connected, the sender waited 8 s for a receipt that could never come and was told the outcome was uncertain, although the message had not reached anyone.
+- A workflow stage registered outside a run (another run's stage, or an isolated subgroup stage of the same run) that tries to send to the run's stages is now told `A workflow stage in <its group> cannot send to stages of workflow:<rootRunId>; joining that group does not grant it control`, instead of being told to join a group that would not help ([#4006](https://github.com/bastani-inc/atomic/issues/4006))
+
 ## [0.9.44] - 2026-10-25
 
 ### Changed

package/dist/builtin/intercom/broker/broker.ts

@@ -72,7 +72,7 @@ import { OUTBOX_BACKUP_POLL_INTERVAL_MS } from "./multinode-state-store.js";
 import { SupervisorChannelCache } from "./supervisor-channel.js";
 import { SessionIdReclaim } from "./session-id-reclaim.js";
 import { type HeldSend, RestoringRecipients } from "./restoring-recipients.js";
-import { hasGroup, normalizeGroup, normalizeGroups } from "../group.js";
+import { hasGroup, normalizeGroup, normalizeGroups, workflowInvocationRefusalFor } from "../group.js";
 import { handleBrokerPresence } from "./presence-handler.js";
 import {
 	knownGroupSummaries,
@@ -121,6 +121,11 @@ interface PendingStageRouteRegistration {
   readonly capability: string;
   /** Registered by a restarted owner for an interrupted run; yields to the process that resumes it (#3760). */
   readonly dormant?: true;
+  /**
+   * #4006: held only by the process that launched the run, never by its stages. Presenting it in
+   * `claim_workflow_invocation` grants that session the invocation's control without membership.
+   */
+  readonly launcherCapability?: string;
 }
 
 interface WorkflowRosterRegistration {
@@ -347,6 +352,11 @@ class IntercomBroker {
   private liveWorkflowStageRoutes = new Map<string, LiveWorkflowStageRouteRegistration>();
   private workflowRosters = new Map<string, WorkflowRosterRegistration>();
   private liveWorkflowStageRouteActivations = new Map<string, LiveWorkflowStageRouteActivation>();
+  /**
+   * #4006: runs each connected session launched, proven with the run's launcher capability. Keyed by session,
+   * then run, holding the capability claimed; a claim lapses when the run's route carries another one.
+   */
+  private workflowInvocationClaims = new Map<string, Map<string, string>>();
   /** Multi-node S5: set only when the agent directory's settings select a top-level shared `storage`. */
   private readonly sharedStorageSetting = readSharedStorageSetting(dirname(INTERCOM_DIR));
   private readonly routeRemote: RemoteSendRouter | undefined =
@@ -649,17 +659,57 @@ class IntercomBroker {
 	}
 
 	/**
-	 * Invocation control may come from the invocation owner or from an ordinary
-	 * host session that explicitly joined the invocation group. A workflow stage
-	 * registered under any workflow group cannot turn mutable membership into a
-	 * parent-control capability for a sibling (or for another workflow run).
+	 * Invocation control may come from the invocation owner, from the session that
+	 * launched the run (#4006), or from an ordinary host session that explicitly
+	 * joined the invocation group. A workflow stage registered under any workflow
+	 * group cannot turn mutable membership into a parent-control capability for a
+	 * sibling (or for another workflow run).
 	 */
 	private canControlWorkflowInvocation(sender: ConnectedSession, invocationGroup: string): boolean {
+		return this.controlsWorkflowInvocationByMembership(sender, invocationGroup) || this.launchedWorkflowInvocation(sender, invocationGroup);
+	}
+
+	private controlsWorkflowInvocationByMembership(sender: ConnectedSession, invocationGroup: string): boolean {
 		if (!hasGroup(sessionGroups(sender.info), invocationGroup)) return false;
 		const registrationGroup = normalizeGroup(sender.registrationGroup);
 		return registrationGroup === invocationGroup || !registrationGroup.startsWith("workflow:");
 	}
 
+	/** #4006: the sender holds a current claim on a run whose route is registered under `invocationGroup`. */
+	private launchedWorkflowInvocation(sender: ConnectedSession, invocationGroup: string): boolean {
+		const claims = this.workflowInvocationClaims.get(sender.info.id);
+		if (claims === undefined) return false;
+		const group = normalizeGroup(invocationGroup);
+		for (const [runId, capability] of claims) {
+			const route = this.pendingStageRoutes.get(runId);
+			if (route?.launcherCapability === capability && normalizeGroup(route.group) === group) return true;
+		}
+		return false;
+	}
+
+	/**
+	 * Only the holder of a run's launcher capability can claim to have launched it. That capability is
+	 * separate from the route capability every stage of the run holds, so a stage cannot claim.
+	 */
+	private claimWorkflowInvocation(sessionId: string, runId: string, capability: string): boolean {
+		const route = this.pendingStageRoutes.get(runId);
+		if (
+			route?.launcherCapability === undefined ||
+			route.launcherCapability !== capability ||
+			!normalizeGroup(route.group).startsWith("workflow:")
+		) {
+			return false;
+		}
+		const claims = this.workflowInvocationClaims.get(sessionId) ?? new Map<string, string>();
+		// Claims on runs whose routes are gone can never authorize again.
+		for (const claimedRunId of claims.keys()) {
+			if (!this.pendingStageRoutes.has(claimedRunId)) claims.delete(claimedRunId);
+		}
+		claims.set(runId, capability);
+		this.workflowInvocationClaims.set(sessionId, claims);
+		return true;
+	}
+
 	private canControlLiveWorkflowStage = (
 		sender: ConnectedSession,
 		target: ConnectedSession,
@@ -723,7 +773,12 @@ class IntercomBroker {
 		const entries: WorkflowFutureStageRosterEntry[] = [];
 		for (const [runId, roster] of this.workflowRosters) {
 			if (roster.possibleStages === undefined || roster.possibleStages.length === 0) continue;
-			if (![...requesterGroups].some((group) => invocationOwnsGroup(roster.group, group))) continue;
+			if (
+				![...requesterGroups].some((group) => invocationOwnsGroup(roster.group, group)) &&
+				!this.launchedWorkflowInvocation(requester, roster.group)
+			) {
+				continue;
+			}
 			if (selected !== undefined && selected !== roster.group) continue;
 			for (const row of roster.possibleStages) {
 				if (this.isNonAgentWorkflowTarget(row.target)) continue;
@@ -899,10 +954,15 @@ class IntercomBroker {
         type: "delivery_failed",
         messageId: route.message.id,
         ...(route.attemptId ? { attemptId: route.attemptId } : {}),
-        reason: "Target workflow run is in a different intercom group",
+        // A workflow stage registered outside the invocation can't gain control by joining; say so.
+        reason: workflowInvocationRefusalFor(route.from.registrationGroup, ownerRegistration.group),
       });
       return true;
     }
+    // #4006: the run's host checks membership again before queueing; say when the broker authorized the launcher instead.
+    const invocationControl =
+      !this.controlsWorkflowInvocationByMembership(route.from, ownerRegistration.group) &&
+      this.launchedWorkflowInvocation(route.from, ownerRegistration.group);
     const requestId = randomUUID();
     const timeout = setTimeout(() => {
       const pending = this.pendingStageAcknowledgments.get(requestId);
@@ -944,6 +1004,7 @@ class IntercomBroker {
 			target: route.target,
         message: route.message,
 		...(route.liveTargetId === undefined ? {} : { live: true }),
+		...(invocationControl ? { invocationControl: true as const } : {}),
       })
     ) {
       // The owner's socket stopped accepting frames between resolving the route
@@ -1220,6 +1281,14 @@ class IntercomBroker {
 							reason: UNCERTAIN_RECEIPT_REASON,
 						});
 					},
+					hold: (waiting, timeoutMs) => {
+						writeMessageIfOpen(waiting.socket, {
+							type: "send_held",
+							messageId: pending.messageId,
+							...(waiting.attemptId === undefined ? {} : { attemptId: waiting.attemptId }),
+							timeoutMs,
+						});
+					},
 				},
 				sender,
 			);
@@ -1375,8 +1444,7 @@ class IntercomBroker {
 			target === undefined ||
 			!isAgentRecipient(target.info) ||
 			target.info.id === currentId ||
-			normalizeGroup(target.registrationGroup) !== routeGroup ||
-			!hasGroup(sessionGroups(target.info), routeGroup)
+			!this.canReceivePendingStageNotification(target, clientMessage.to, routeGroup)
 		) {
 			this.failPendingStageNotification(socket, message.id, attemptId, "Session not found");
 			return;
@@ -1459,6 +1527,19 @@ class IntercomBroker {
 		}
 	}
 
+	/**
+	 * A pending-stage notice reaches a session registered in the run's group, or (#4006) the exact
+	 * sender session that controls the run from outside it: the launcher holding a current claim, or
+	 * an ordinary session that joined `workflow:<rootRunId>`. Isolated stages never qualify, and the
+	 * legacy name/return-address fallbacks stay limited to the run's own group.
+	 */
+	private canReceivePendingStageNotification(target: ConnectedSession, to: string, routeGroup: string): boolean {
+		if (normalizeGroup(target.registrationGroup) === routeGroup && hasGroup(sessionGroups(target.info), routeGroup)) {
+			return true;
+		}
+		return target.info.id === to && this.canControlWorkflowInvocation(target, routeGroup);
+	}
+
 	private settlePendingStageNotification(
 		currentId: string,
 		requestId: string,
@@ -1636,6 +1717,8 @@ class IntercomBroker {
             acknowledgesPendingStageRoutes: true as const,
             refusesPendingStageRoutesInPlace: true as const,
             brokerStatus: true as const,
+            claimsWorkflowInvocations: true as const,
+            extendsSaves: true as const,
           });
           if (isAgentRecipient(info)) this.broadcastToMemberships({ type: "session_joined", session: info }, sessionGroups(info), id);
           // #3761: messages written to this recipient's previous connection that it never confirmed saving go out again.
@@ -1835,10 +1918,13 @@ class IntercomBroker {
           typeof clientMessage.group !== "string" ||
           typeof clientMessage.capability !== "string" ||
           !clientMessage.capability ||
-          (clientMessage.requestId !== undefined && typeof clientMessage.requestId !== "string")
+          (clientMessage.requestId !== undefined && typeof clientMessage.requestId !== "string") ||
+          (clientMessage.launcherCapability !== undefined &&
+            (typeof clientMessage.launcherCapability !== "string" || !clientMessage.launcherCapability))
         ) {
           throw new Error("Invalid pending-stage route registration");
         }
+        const launcherCapability = clientMessage.launcherCapability;
         const routeRequestId = clientMessage.requestId;
         // The route is applied synchronously, so this answer proves the update is visible to every later request.
         const acknowledgeRoute = (): void => {
@@ -1955,6 +2041,7 @@ class IntercomBroker {
           group: ownerGroup,
           capability: clientMessage.capability,
           ...(dormant ? { dormant: true as const } : {}),
+          ...(launcherCapability === undefined ? {} : { launcherCapability }),
         });
         if (yieldedDormant !== undefined) {
           const revoked = this.sessions.get(yieldedDormant.sessionId);
@@ -1975,6 +2062,24 @@ class IntercomBroker {
         break;
       }
 
+      case "claim_workflow_invocation": {
+        if (
+          typeof clientMessage.requestId !== "string" ||
+          typeof clientMessage.runId !== "string" ||
+          typeof clientMessage.capability !== "string" ||
+          !clientMessage.capability ||
+          currentId === null
+        ) {
+          throw new Error("Invalid workflow invocation claim");
+        }
+        writeMessageIfOpen(socket, {
+          type: "workflow_invocation_claimed",
+          requestId: clientMessage.requestId,
+          claimed: this.claimWorkflowInvocation(currentId, clientMessage.runId, clientMessage.capability),
+        });
+        break;
+      }
+
       case "register_live_workflow_stage_route": {
         if (
           typeof clientMessage.requestId !== "string" ||
@@ -2092,6 +2197,14 @@ class IntercomBroker {
 			break;
 		}
 
+		case "saving": {
+			if (typeof clientMessage.messageId !== "string") throw new Error("Invalid saving message");
+			const recipient = this.sessions.get(currentId);
+			if (recipient?.acknowledgesReceipt === true && !this.multiNode?.saving(recipient, clientMessage.messageId))
+				this.receipts.extend(clientMessage.messageId, deliveryTargetIdentity(recipient));
+			break;
+		}
+
 		case "send_pending_stage_notification": {
 			this.handlePendingStageNotificationSend(socket, clientMessage, currentId);
 			break;
@@ -2384,6 +2497,7 @@ class IntercomBroker {
 	for (const [requestId, activation] of this.liveWorkflowStageRouteActivations) {
 		if (activation.sessionId === sessionId) this.liveWorkflowStageRouteActivations.delete(requestId);
 	}
+	this.workflowInvocationClaims.delete(sessionId);
 	this.sessions.delete(sessionId);
 	this.multiNode?.sessionLeft(departed);
 	this.sessionIdReclaim.retire(sessionId, departed.registrationReturnAddress);