pi-subagents 0.79.1 → 0.80.0

package/CHANGELOG.md

@@ -2,6 +2,55 @@
 
 ## [Unreleased]
 
+## [0.80.0] - 2026-10-21
+
+### Highlights
+
+- pi-subagents now needs Pi 1.2.0 or newer. In return, waking an idle parent no longer adds an "Inspect subagent updates above" line to your transcript: the subagent's own notice starts the turn.
+- `parallel`, `tasks` and `chain` children can each set their own `cwd` and `model`, so one call can fan out across repositories or worktrees, or mix models, without writing a workflow script.
+- `enableSlashCommands: false` keeps the `subagent` tool and drops every pi-subagents slash command, for setups that delegate only through the model.
+- The folded widget line shows how long the current batch of work has been running, for example `subagents (1/1 running 13s)`.
+- Windows: Pi no longer exits at startup when security software blocks `git`. DeepSeek and other providers that reuse the Codex Responses wire no longer fail on a child's second tool call.
+
+### Added
+
+- Children of the built-in `parallel` workflow (`args.tasks`), and `tasks` items and `chain` steps and group members when workflow scripts are disabled, accept optional `cwd` and `model`. One call can now fan out across several repositories or worktrees, or mix models, without writing a script. Before, these fields were rejected with "accepts only agent and task". Thanks to [@andresutre](https://github.com/andresutre) for [#2985](https://github.com/nicobailon/pi-subagents/pull/2985).
+- The folded async widget line now shows how long the current stretch of running work has lasted, for example `subagents (1/1 running 13s)`. It counts from the oldest running job, so it stays right after a session resume, and it disappears once nothing is running. Thanks to [@summer-tt](https://github.com/summer-tt) for [#2979](https://github.com/nicobailon/pi-subagents/pull/2979).
+- `enableSlashCommands: false` in the extension config keeps the `subagent` tool and drops every pi-subagents slash command and the foreground-detach shortcut, for setups that delegate only through the model or want fewer global commands. Prompt shortcuts such as `/parallel-review` are Pi prompt templates, and Pi's package filter (`"prompts": []`) already removes them. See [configuration](docs/configuration.md#enableslashcommands). Thanks to [@khavronin-artem](https://github.com/khavronin-artem) for requesting it in [#2977](https://github.com/nicobailon/pi-subagents/issues/2977).
+
+### Changed
+
+- pi-subagents now needs Pi 1.2.0 or newer; Pi 0.86.1 and 1.0.0 are no longer supported. The supported standalone target is now the official Pi 1.2.0 Linux x64 release. Pi 1.2.0 lets an extension message start a turn with the full system prompt, so an idle parent is now woken by the subagent notice itself, and the transcript no longer gets a separate "Inspect subagent updates above" line on every wake. Each notice says what the parent should do next. Thanks to [@summer-tt](https://github.com/summer-tt) for [#2976](https://github.com/nicobailon/pi-subagents/issues/2976).
+- The npm package no longer ships source maps. They pointed at TypeScript sources the package does not include, so nothing could use them, and they were almost half its files: the unpacked install drops from 12.1 MB to 6.8 MB and the download from 2.5 MB to 1.6 MB. Thanks to [@tututuhehehe](https://github.com/tututuhehehe) for reporting it in [#2980](https://github.com/nicobailon/pi-subagents/issues/2980).
+
+### Fixed
+
+- Pi could exit at session start on Windows when security software stopped it from launching `git` (`spawn EPERM`). The watchdog now starts without its diff baseline in that case, as it already did when `git` was missing. Thanks to [@advaitpaliwal](https://github.com/advaitpaliwal) for reporting [#2978](https://github.com/nicobailon/pi-subagents/issues/2978).
+- Children on a custom provider that speaks the Codex Responses wire under its own api id, such as `pi-cliproxyapi`'s `cliproxyapi-codex-responses`, had their tool-call ids rewritten, and DeepSeek rejected the second tool turn with a misleading "`reasoning_text` ... must be passed back" error. Any `*-codex-responses` api now keeps its ids the way `openai-codex-responses` does. Thanks to [@xspeed1989](https://github.com/xspeed1989) for reporting [#2981](https://github.com/nicobailon/pi-subagents/issues/2981).
+- Subagent cards said "Configure the expand key for live detail" when Pi's keybindings were not loaded, for example in an HTML session export, although the key was bound (`ctrl+o` by default). They now say "Press the expand key for live detail", and in RPC mode the status line of slash-command launches such as `/run` no longer shows an empty key (`3 tools |  live detail`). Thanks to [@JohannesBertens](https://github.com/JohannesBertens) for [#2983](https://github.com/nicobailon/pi-subagents/pull/2983) ([#2982](https://github.com/nicobailon/pi-subagents/issues/2982)).
+- On Pi 1.2, a child's bash command that exited non-zero showed as `completed` in `subagent_command` status. It now shows as `failed`.
+
+## [0.79.2] - 2026-10-20
+
+### Highlights
+
+- A background child that finishes while you are busy no longer loses its completion notice if Pi restarts before you get to it. The next Pi that opens the session shows it.
+- Steering is less fragile. A steer that times out waiting for a busy child no longer blocks every later steer on that run, and a steer that arrives too late says what state the run is in and what to do next.
+- Children no longer pick up your `APPEND_SYSTEM.md`, on this machine or on a saved Herdr machine. It was meant for your main session.
+- Workflows relaunched after a reload give back their background-run capacity, and workflows started from providers with very long tool-call ids (LiteLLM with Gemini) no longer fail at launch.
+- A session compacted by an older Pi can no longer lose `subagent` for good.
+
+### Fixed
+
+- A background subagent that finished while the parent was busy could lose its completion notice if Pi restarted before the parent got to it: Pi drops a queued notice when the session ends, and the result file was already gone. Such a notice is now saved in the session when it ends, and the next Pi process that opens the session, for example after a restart or with `pi --continue`, resends it and wakes the parent. A notice already in the session is not sent twice, notices on another branch of the session tree don't count, and `/reload` is unchanged. Thanks to [@advaitpaliwal](https://github.com/advaitpaliwal) for [#2968](https://github.com/nicobailon/pi-subagents/pull/2968).
+- A default `steer` on a running child that didn't pause within the recovery wait left the run locked, so every later steer failed with "Another steering recovery is already committed". A timed-out attempt now unlocks the run, still starts no replacement, and its error gives the real wait, the run's last state, that the message wasn't applied, and that `action: "resume"` continues the run. Thanks to [@tglunde](https://github.com/tglunde) for reporting [#2956](https://github.com/nicobailon/pi-subagents/issues/2956).
+- `steer` on a run that had already finished said only that it "is not running or queued". It now names the run's state and the next step: a completed retained child points at `mode: "follow_up"` or `resume`, and other runs point at `resume` only when resume would accept them, otherwise giving resume's own reason (for example, a stopped run has to be started again). Thanks to [@armchairfuturist-code](https://github.com/armchairfuturist-code) for [#2955](https://github.com/nicobailon/pi-subagents/pull/2955) ([#2954](https://github.com/nicobailon/pi-subagents/issues/2954)).
+- Children launched with `systemPromptMode: replace` (every builtin except `delegate`) received the operator's `APPEND_SYSTEM.md`, because Pi fills an empty append-prompt slot from that file. They now start without it, like `delegate` children and like the operator's global `AGENTS.md`. Children on a saved Herdr machine no longer get the remote operator's file either. To give a child those instructions, put them in the agent's prompt or an `agentOverrides` `systemPrompt`. Thanks to [@scnbln](https://github.com/scnbln) for [#2961](https://github.com/nicobailon/pi-subagents/pull/2961) ([#2960](https://github.com/nicobailon/pi-subagents/issues/2960), [#2969](https://github.com/nicobailon/pi-subagents/issues/2969)).
+- An async workflow relaunched after a reload kept its slot in `maxActiveAsyncRunsPerSession` forever when it reused finished children, re-attached to running ones, or had a child stopped before it started, so a long-lived session could run out of capacity. The slot is now released once the reused runs have ended. Slots already held by earlier versions are not reclaimed. Thanks to [@peterdsharpe](https://github.com/peterdsharpe) for reporting [#2958](https://github.com/nicobailon/pi-subagents/issues/2958) and the fix it describes.
+- A workflow launched from a tool call whose id was over 4,096 bytes failed with "parentToolCallId must be a non-empty identifier of at most 4096 UTF-8 bytes". LiteLLM, for example, puts Gemini thought signatures in the tool-call id. The workflow now runs; the workflow summary records a short digest of the id, and the run's `status.json` still keeps the full id. Thanks to [@mxr576](https://github.com/mxr576) for reporting [#2962](https://github.com/nicobailon/pi-subagents/issues/2962).
+- A session compacted by an older Pi, which kept no record of the session's tools, could lose `subagent` for good: on resume the surviving messages read as a deliberate choice to turn it off, and in `auto` mode nothing could turn it back on, not even `/reload`. Such a session now gets the tools a new session would, the same way on resume, `/reload` and tree navigation, and sessions already left without them recover. A choice to turn tools off made after the compaction is still kept. Thanks to [@jbachorik](https://github.com/jbachorik) for [#2963](https://github.com/nicobailon/pi-subagents/pull/2963).
+- The unit tests no longer fail when run from a shell that Pi or a pi-subagents child started, or on Node 24 under macOS. Thanks to [@jbachorik](https://github.com/jbachorik) for reporting [#2964](https://github.com/nicobailon/pi-subagents/issues/2964), [#2965](https://github.com/nicobailon/pi-subagents/issues/2965) and [#2966](https://github.com/nicobailon/pi-subagents/issues/2966).
+
 ## [0.79.1] - 2026-10-17
 
 ### Highlights

package/README.md

@@ -14,7 +14,7 @@
 pi install npm:pi-subagents
 ```
 
-That is the only required step. Background children use the host's SDK: npm Pi keeps its detached Node runner; the official Pi 0.86.1 Linux x64 standalone release loads the same runner through Pi's embedded SDK, without a separate SDK install. See [Standalone background execution](docs/standalone-background.md) for the supported boundary and validation gate.
+That is the only required step. pi-subagents needs Pi 1.2.0 or newer. Background children use the host's SDK: npm Pi keeps its detached Node runner; the official Pi 1.2.0 Linux x64 standalone release loads the same runner through Pi's embedded SDK, without a separate SDK install. See [Standalone background execution](docs/standalone-background.md) for the supported boundary and validation gate.
 
 ## Try this first
 

package/docs/agents.md

@@ -539,7 +539,7 @@ Examples:
 
 ### MCP tools
 
-When [pi-mcp-adapter](https://github.com/nicobailon/pi-mcp-adapter) is not installed and Pi has built-in MCP (Pi 0.99.2 or later), `mcp:server` and `mcp:server/tool` entries resolve against Pi's built-in MCP. Name the server and tool as the server reports them: `mcp:my-docs/get-item` selects the tool Pi registers as `mcp__my_docs__get_item`. The server part may also use the `-`→`_` form of its name that Pi's MCP namespace uses, such as `mcp:my_docs`. The child connects the servers in Pi's `mcp.json` (the project's `.pi/mcp.json` only when the parent trusts the project) and gets only the selected tools, as direct tools, whatever exposure the server is configured with; tools configured as `hidden` cannot be selected. Servers that an extension adds with `pi.registerMcpServer()` work in background children, because the registering extension loads there too. They do not work in foreground children, which load no ambient extensions, so a foreground launch that selects one fails and says to use `async: true`. The child waits for the selected servers' current MCP connection attempts before its first prompt, then rejects the launch if any selected tool is missing or not available as a direct tool. Pi's MCP request timeout still bounds each connection; stopping, interrupting, timing out, or shutting down the child cancels the startup wait. An unrelated server does not delay this check.
+When [pi-mcp-adapter](https://github.com/nicobailon/pi-mcp-adapter) is not installed, `mcp:server` and `mcp:server/tool` entries resolve against Pi's built-in MCP. Name the server and tool as the server reports them: `mcp:my-docs/get-item` selects the tool Pi registers as `mcp__my_docs__get_item`. The server part may also use the `-`→`_` form of its name that Pi's MCP namespace uses, such as `mcp:my_docs`. The child connects the servers in Pi's `mcp.json` (the project's `.pi/mcp.json` only when the parent trusts the project) and gets only the selected tools, as direct tools, whatever exposure the server is configured with; tools configured as `hidden` cannot be selected. Servers that an extension adds with `pi.registerMcpServer()` work in background children, because the registering extension loads there too. They do not work in foreground children, which load no ambient extensions, so a foreground launch that selects one fails and says to use `async: true`. The child waits for the selected servers' current MCP connection attempts before its first prompt, then rejects the launch if any selected tool is missing or not available as a direct tool. Pi's MCP request timeout still bounds each connection; stopping, interrupting, timing out, or shutting down the child cancels the startup wait. An unrelated server does not delay this check.
 
 When pi-mcp-adapter is installed, it keeps priority and provides the direct MCP tools. Subagents only receive direct MCP tools when `mcp:` entries are listed in their frontmatter; global `directTools: true` in the adapter's MCP config is not enough by itself. The generic `mcp` proxy tool can still be used for discovery when available. The adapter caches tool metadata at startup, so after connecting a new MCP server for the first time, restart Pi before relying on direct tools. Server `includeTools` and `excludeTools` policies are enforced while resolving cached metadata for children: both accept exact names and `*`/`?` glob patterns against raw, generated-resource, and server/short/mcp/none-prefixed names, with `excludeTools` taking precedence. `mcp:` entries must name servers from the adapter's configuration files. A server that exists only in the adapter's runtime snapshot (registered at runtime, not persisted) cannot be provided to a child: children are pi sessions inside the parent or the runner process, not `pi` processes that could receive an MCP config argument, so such a launch fails with an error saying that MCP tools must come from an ambient adapter extension in a background child. An `mcp:` entry named `subagent` does not authorize nested fanout; declare the builtin `subagent` tool or set `allowNestedSubagents: true`. If a resolved direct MCP name is missing from the child registry, pi-subagents keeps the launch failed under the strict allowlist and reports the registration mismatch; check the resolved names against what the host or pi-mcp-adapter actually registers before child startup.
 

package/docs/configuration.md

@@ -80,9 +80,9 @@ A local Pi child whose selected model is a virtual model (`pi.registerVirtualMod
 
 ## Tool activation lifecycle
 
-On Pi 0.86.1 or newer, when the model can take a new tool mid-conversation (see [`toolActivation`](#toolactivation)), a fresh unrestricted parent starts with only `subagents_enable` active while `subagent`, `bg_wait`, and `subagent_supervisor` stay registered but inactive. Calling `subagents_enable({})` preserves unrelated active tools and exposes all three on the next model request. It does not launch a child or infer authority from prompt keywords. `bg_wait` is also declared without `subagent` once another extension registers a [background-work provider](extension-api.md#background-work-provider-api), because only `bg_wait` waits for that work. `subagent_supervisor`, which answers this session's children, is also declared when a child request reaches a session that does not have it, such as one from a scheduled run. With other models, a fresh parent starts with `subagent`, `bg_wait`, and `subagent_supervisor` active and no `subagents_enable`. `contact_supervisor` is active whenever `subagent` is, with the definition children use, so a forked child declares the same tools as its parent and can reuse its prompt cache; called in a session that is not a subagent, it returns an error.
+When the model can take a new tool mid-conversation (see [`toolActivation`](#toolactivation)), a fresh unrestricted parent starts with only `subagents_enable` active while `subagent`, `bg_wait`, and `subagent_supervisor` stay registered but inactive. Calling `subagents_enable({})` preserves unrelated active tools and exposes all three on the next model request. It does not launch a child or infer authority from prompt keywords. `bg_wait` is also declared without `subagent` once another extension registers a [background-work provider](extension-api.md#background-work-provider-api), because only `bg_wait` waits for that work. `subagent_supervisor`, which answers this session's children, is also declared when a child request reaches a session that does not have it, such as one from a scheduled run. With other models, a fresh parent starts with `subagent`, `bg_wait`, and `subagent_supervisor` active and no `subagents_enable`. `contact_supervisor` is active whenever `subagent` is, with the definition children use, so a forked child declares the same tools as its parent and can reuse its prompt cache; called in a session that is not a subagent, it returns an error.
 
-The recorded native `subagent` selection is restored on resume, reload, and tree navigation, so an activated session stays activated and a cold session stays cold. The recorded `bg_wait` and `subagent_supervisor` selections are restored the same way, so a session that declared them, for example on an earlier version, keeps them. With the default `toolActivation`, the recorded `subagents_enable` selection is restored too, so a session that started without the loader never gets it later. Older history without tool-selection records keeps eager `subagent`, `bg_wait`, and `subagent_supervisor` availability. If Pi's allowlist or exclusions remove the loader, the extension does not hide `subagent` or `bg_wait`; if they remove `subagent`, the loader reports it unavailable. Hosts whose extension API lacks `getAllTools`, `getActiveTools`, or `setActiveTools` keep eager behavior and log one compatibility warning. The host version is not read from disk, so in-process hosts such as pi-web activate the same way as the Pi CLI.
+The recorded native `subagent` selection is restored on resume, reload, and tree navigation, so an activated session stays activated and a cold session stays cold. The recorded `bg_wait` and `subagent_supervisor` selections are restored the same way, so a session that declared them, for example on an earlier version, keeps them. With the default `toolActivation`, the recorded `subagents_enable` selection is restored too, so a session that started without the loader never gets it later. Older history without tool-selection records keeps eager `subagent`, `bg_wait`, and `subagent_supervisor` availability. If Pi's allowlist or exclusions remove the loader, the extension does not hide `subagent` or `bg_wait`; if they remove `subagent`, the loader reports it unavailable. The host version is not read from disk, so in-process hosts such as pi-web activate the same way as the Pi CLI.
 
 Some providers fix the tool list for a whole prompt, for example bridges that hand Pi's tools to another agent SDK. There `subagent` appears only on the next user prompt, not the next model request. Start Pi with `--exclude-tools subagents_enable` to keep `subagent` active from the start.
 
@@ -98,7 +98,7 @@ Controls how a new parent session offers the `subagent` tool. The default is `"a
 - `"dynamic"`: every new session starts with the loader, whatever the model. This was the behavior before `toolActivation` existed.
 - `"eager"`: the loader is not registered, so `subagent` is active from the first request, as with `--exclude-tools subagents_enable`. A resumed session that recorded the loader changes its tool list once on the next request.
 
-The choice is made at session start or tree navigation, and only for a session with no messages. Resumed sessions keep the tools they recorded, and switching models mid-session does not change them. `"auto"` avoids only the loader's cache miss; other tool-list or provider changes can still miss the cache. An active `subagent` sends its full schema on every request. An invalid value is a config error, not a fallback to the default. Restart Pi after changing it.
+The choice is made at session start or tree navigation, and only for a session with no messages. If a compaction that kept no tool checkpoint dropped the record of this choice, the session is decided again as a new session would be; tool selections recorded after that compaction (for `bg_wait` or another extension's tools) are not evidence that the choice survived. Resumed sessions keep the tools they recorded, and switching models mid-session does not change them. `"auto"` avoids only the loader's cache miss; other tool-list or provider changes can still miss the cache. An active `subagent` sends its full schema on every request. An invalid value is a config error, not a fallback to the default. Restart Pi after changing it.
 
 ## `toolDescriptionMode`
 
@@ -150,8 +150,8 @@ Disabling a per-call option removes only the per-call override. Configured defau
 
 `workflow-scripts` removes workflow scripts and named workflow resources from every entry point. The model can no longer write a script, and a script that still arrives from RPC `spawn` (`script` or `workflow`), `/prompt-workflow`, a saved schedule, or a delegated launch fails with an error that names the setting. Schedule inspection, pause, and delete still work, but `schedule.create` cannot succeed because it needs a script. `/run` still works: it launches its one child directly. The built-in tool description and prompt snippet drop the script guidance and describe two small inputs instead:
 
-- `tasks: [{ agent, task }, ...]` runs the children in parallel and returns their results in order.
-- `chain: [step, ...]` runs steps in order. A step is `{ agent, task?, as? }` or a parallel group `{ parallel: [{ agent, task }, ...] }`. A group waits for all of its children.
+- `tasks: [{ agent, task, cwd?, model? }, ...]` runs the children in parallel and returns their results in order.
+- `chain: [step, ...]` runs steps in order. A step is `{ agent, task?, as?, cwd?, model? }` or a parallel group `{ parallel: [{ agent, task, cwd?, model? }, ...] }`. A group waits for all of its children. `cwd` and `model` are optional and apply to that one child.
 
 A top-level `task` is the original request. Tasks can use three placeholders:
 
@@ -194,6 +194,16 @@ With `"summary"`, a tool result looks like this:
 ✓ reviewer · completed
 ```
 
+## `enableSlashCommands`
+
+```json
+{ "enableSlashCommands": false }
+```
+
+Set to `false` to register none of the pi-subagents slash commands (`/run`, `/subagents`, `/subagents-fleet`, `/subagents-watchdog`, `/prompt-workflow`, and the rest) and no [`foregroundDetachShortcut`](#foregrounddetachshortcut). The `subagent` tool, RPC, the async widget, and the extension's other features are unchanged. Prompt templates whose frontmatter has `chain:` launch through `/prompt-workflow`, so they stop working too. Defaults to `true`. Restart Pi or run `/reload` after changing it.
+
+The package's prompt shortcuts, such as `/parallel-review` and `/review-loop`, are Pi prompt templates, not commands, so this setting leaves them alone. Pi's package filter removes them: `{ "packages": [{ "source": "npm:pi-subagents", "prompts": [] }] }` in Pi's `settings.json`, or `pi config`.
+
 ## `foregroundDetachShortcut`
 
 ```json
@@ -359,7 +369,7 @@ Reports are sent only from an interactive TUI session whose standard output is a
 | failed, partial, or rejected | `error` |
 | stopped or paused | `idle` |
 
-Each record's `title` is the agent names or workflow key, and its `msg` is the current tool while working, or the outcome. Neither includes the task text. Finished runs keep their `done`, `error`, or `idle` record after they leave the async widget, for as long as they are in Fleet's recent history (the last 20 finished runs). Records of runs this session no longer tracks, for example after switching sessions, are cleared. At most 64 records are shown: running and waiting runs first, then finished ones, most recently updated first; older finished records are cleared to make room. When the extension is reloaded or the session is replaced, it clears every record it sent and the new session reports the runs it still tracks. Pi 1.1 and later reports its own state on the root record and clears every record, these included, when it quits, suspends with Ctrl+Z, or opens an external editor. After a suspend, this extension sends its records again; after an external editor, each record comes back the next time it changes. Foreground runs are not reported, and tmux drops these sequences unless you configure passthrough.
+Each record's `title` is the agent names or workflow key, and its `msg` is the current tool while working, or the outcome. Neither includes the task text. Finished runs keep their `done`, `error`, or `idle` record after they leave the async widget, for as long as they are in Fleet's recent history (the last 20 finished runs). Records of runs this session no longer tracks, for example after switching sessions, are cleared. At most 64 records are shown: running and waiting runs first, then finished ones, most recently updated first; older finished records are cleared to make room. When the extension is reloaded or the session is replaced, it clears every record it sent and the new session reports the runs it still tracks. Pi reports its own state on the root record and clears every record, these included, when it quits, suspends with Ctrl+Z, or opens an external editor. After a suspend, this extension sends its records again; after an external editor, each record comes back the next time it changes. Foreground runs are not reported, and tmux drops these sequences unless you configure passthrough.
 
 ## `activeRunsPrompt`
 

package/docs/extension-api.md

@@ -600,7 +600,7 @@ The API returns discriminated structured results with canonical project root, bi
 
 A host that embeds this extension owns whether completion wakes can be delivered at all.
 
-Ordinary async and foreground completion wakes use `registerSubagentNotify` and `sendCompletion`. They listen for completion events and deliver through `pi.sendMessage(..., { triggerTurn })`. When the parent is idle, every pi-subagents notice that should start a turn (completions, supervisor asks, control and steering notices, wait subscriptions) is instead appended without a turn, followed by one user message, `PARENT_WAKE_TEXT` from `src/shared/parent-wake.ts`, sent with `pi.sendUserMessage`. Pi runs `before_agent_start` only for prompts, so this keeps extension-set system prompt sections in the woken run. A busy parent still gets the notice as a steering message. After the user aborts a parent run in a host with a UI, these notices are only appended, with no turn and no wake message, until the next parent run starts. Session shutdown stops the result watcher and disposes this completion notifier. `createWaitSubscriptionManager` is separate: it is the explicit non-blocking `bg_wait` subscription path for work without native notification, not the ordinary completion wake path.
+Ordinary async and foreground completion wakes use `registerSubagentNotify` and `sendCompletion`. They listen for completion events and deliver through `pi.sendMessage(..., { triggerTurn })`. When the parent is idle, every pi-subagents notice that should start a turn (completions, supervisor asks, control and steering notices, wait subscriptions) starts the run itself with `triggerTurn: true`; Pi runs `before_agent_start` for that run, so extension-set system prompt sections stay in it. Each such notice ends with what the parent should do (for completions, `Parent action: ...`), and no separate user message is sent. If another extension's wake (pi-intercom's, through the shared `Symbol.for("pi.idle-wake.v1")` reservation) is already starting the run, the notice is appended without a turn and that run picks it up. A busy parent still gets the notice as a steering message. After the user aborts a parent run in a host with a UI, these notices are only appended, with no turn, until the next parent run starts. Session shutdown stops the result watcher and disposes this completion notifier. `createWaitSubscriptionManager` is separate: it is the explicit non-blocking `bg_wait` subscription path for work without native notification, not the ordinary completion wake path.
 
 Each completion notice is a custom message with `customType: "subagent-notify"`. Its `content` is the text the model reads. Pi does not send `details` to the model, so hosts can use it to match a notice to its runs by id without parsing the text. `details.runs` has one entry per finished run, in the order of the notice. A grouped notice has several entries. Each entry has `agent` and `status` (`completed`, `failed`, `paused` or `stopped`). When known, an entry also has these fields:
 
@@ -616,7 +616,7 @@ Detached children do not stop when the session does. They are the host process's
 
 This matters because "is the parent busy?" is the wrong idle signal. A parent that launches a detached run and hands control back — which is what the async launch output tells it to do — is not prompting, streaming, compacting, or running a shell command. A host that reaps sessions on those signals alone will dispose exactly the session that was waiting to be woken.
 
-When pi-subagents runs inside a compatible pi-web host, it discovers the versioned `Symbol.for("@agegr/pi-web/session-liveness/v1")` registry and registers one provider for the current session. The provider reports live `queued`/`running` async jobs, active nested descendants (including foreground routes retained after their direct parent settles), foreground controls that still have a scheduling owner or active child, async runs that ended but whose result has not reached the parent (including a rejected send waiting for retry), completion notifications until Pi starts the wake message (`message_start`), even when Pi queued it behind the current turn or past `agent_settled`, and a wake prompt sent to an idle parent until its run starts (`agent_start`). Accepted wakes remain owned by the same Pi session manager and session UUID across extension reloads, until they start. Independent session managers never share this ownership, and changing the UUID on an existing manager discards the old session's wakes. A wake message Pi discards without starting keeps the session live until the session shuts down for a reason other than reload. A wake prompt whose run has not started 10 seconds later, while the parent is idle, no longer keeps the session live: an input handler consumed it or it failed, and its notices are already in the session. Retained terminal history, future schedules, and wait subscriptions do not make a session live by themselves. The registration is replaced on session changes and released during runtime shutdown or reload; other hosts remain unaffected.
+When pi-subagents runs inside a compatible pi-web host, it discovers the versioned `Symbol.for("@agegr/pi-web/session-liveness/v1")` registry and registers one provider for the current session. The provider reports live `queued`/`running` async jobs, active nested descendants (including foreground routes retained after their direct parent settles), foreground controls that still have a scheduling owner or active child, async runs that ended but whose result has not reached the parent (including a rejected send waiting for retry), completion notifications until Pi starts the wake message (`message_start`), even when Pi queued it behind the current turn or past `agent_settled`, and a turn-triggering notice sent to an idle parent until its run starts (`agent_start`). Accepted wakes remain owned by the same Pi session manager and session UUID across extension reloads, until they start. Independent session managers never share this ownership, and changing the UUID on an existing manager discards the old session's wakes. A wake message Pi discards without starting keeps the session live until the session shuts down for a reason other than reload. An idle wake whose run has not started 10 seconds later, while the parent is idle, stops holding the session live on its own; a completion notice whose run never started is still held by the undelivered-notice tracking above until the session shuts down, which records it for replay at the next start. Retained terminal history, future schedules, and wait subscriptions do not make a session live by themselves. The registration is replaced on session changes and released during runtime shutdown or reload; other hosts remain unaffected.
 
 If your host reclaims idle sessions, keep a session alive while it still has live detached work:
 

package/docs/standalone-background.md

@@ -1,6 +1,6 @@
 # Standalone background execution
 
-Supported standalone target: **official Pi 0.86.1, Linux x64**. Keep its adjacent release assets with the executable. Other versions, operating systems, architectures and packagers are outside the fully validated support target; limited experimental Windows coverage is described below.
+Supported standalone target: **official Pi 1.2.0, Linux x64**. Keep its adjacent release assets with the executable. Other versions, operating systems, architectures and packagers are outside the fully validated support target; limited experimental Windows coverage is described below.
 
 Pi's extension loader supplies its embedded SDK to `binary-bootstrap.ts`, which awaits the existing configured runner before exiting. Startup authorization, revival leases, controls, disposal and process-close observation remain shared with npm. Each independent run has its own host; native sessions inside that run share it. No per-session CLI protocol, runtime download/install, alternate SDK or foreground fallback is introduced. Npm Pi keeps its Node runner, peer aliases and detected npm `PI_PACKAGE_DIR` override (including refusal when no npm root exists).
 
@@ -39,11 +39,11 @@ For a focused diagnostic, use `node test/smoke/standalone-background.mjs "$relea
 
 ## Npm regressions and local trial
 
-Existing npm clean-install CI covers real SDK 0.86.1. The standalone CI job also checks the public npm launch path without execution-time network:
+Existing npm clean-install CI covers real SDK 1.2.0. The standalone CI job also checks the public npm launch path without execution-time network:
 
 ```bash
 npm_checks="$(mktemp -d)"
-node test/smoke/clean-install.mjs "$npm_checks/sdk" 0.86.1
+node test/smoke/clean-install.mjs "$npm_checks/sdk" 1.2.0
 node test/smoke/npm-background.mjs "$npm_checks/sdk" "$npm_checks/launch"
 ```
 

package/docs/workflows.md

@@ -115,7 +115,7 @@ subagent({ workflow: "parallel", args: { tasks: [{ agent: "reviewer", task: "Rev
 
 The host resolves the name and validates bounded plain-JSON `args` before starting the workflow. Resource provenance is recorded in workflow details and receipts for downstream permission/policy checks. Resource authority is not caller-supplied: `runs.host` is available only when the resolved resource explicitly grants the requested host key and command. Reply-block (`workflow: true`) and file-path scripts remain raw, unknown-provenance inputs, so their `runs.host` calls are unavailable through the public execution boundary. Named resources cannot be combined with `agent` or `task`; the package ships the `review`, `run-ci` and `parallel` resources, not a user/project resource registry.
 
-`parallel` runs independent children together without writing a script: `args.tasks` is a list of `{ agent, task }` items, the children run in one `runs.all` batch, and the result lists each child's output in order. A failed child fails the workflow. Use a workflow script when steps depend on each other.
+`parallel` runs independent children together without writing a script: `args.tasks` is a list of `{ agent, task, cwd?, model? }` items, the children run in one `runs.all` batch, and the result lists each child's output in order. `cwd` and `model` are optional per child and apply to that child only, as they do on a `runs.all` item, so one call can fan out across several repositories or mix models. A failed child fails the workflow. Use a workflow script when steps depend on each other.
 
 ### Opt-in bounded workflows
 

package/index.d.ts

@@ -1,3 +1,2 @@
 import type { ExtensionAPI } from "@earendil-works/pi-coding-agent";
 export default function registerSubagentExtension(pi: ExtensionAPI): void;
-//# sourceMappingURL=index.d.ts.map

package/index.js

@@ -12,4 +12,3 @@ export default function registerSubagentExtension(pi) {
     }
     registerExtension?.(pi);
 }
-//# sourceMappingURL=index.js.map

package/package.json

@@ -1,7 +1,7 @@
 {
   "type": "module",
   "name": "pi-subagents",
-  "version": "0.79.1",
+  "version": "0.80.0",
   "description": "Pi extension for single-agent delegation and scripted multi-agent workflows",
   "author": "Nico Bailon",
   "license": "MIT",
@@ -25,7 +25,7 @@
   },
   "peerDependencies": {
     "@earendil-works/pi-agent-core": "*",
-    "@earendil-works/pi-ai": ">=0.86.1",
+    "@earendil-works/pi-ai": ">=1.2.0",
     "@earendil-works/pi-coding-agent": "*",
     "@earendil-works/pi-tui": "*",
     "typebox": "*"

package/src/agents/advertised-agent-prompt.d.ts

@@ -11,4 +11,3 @@ import type { AgentConfig } from "./agents.ts";
  */
 export declare function buildAdvertisedAgentCatalog(agents: readonly AgentConfig[], capabilityCeiling?: ResolvedSubagentCapabilityCeiling, recordedCatalog?: string): string | undefined;
 export declare function buildAdvertisedAgentPrompt(agents: readonly AgentConfig[], capabilityCeiling?: ResolvedSubagentCapabilityCeiling): string | undefined;
-//# sourceMappingURL=advertised-agent-prompt.d.ts.map

package/src/agents/advertised-agent-prompt.js

@@ -66,4 +66,3 @@ export function buildAdvertisedAgentPrompt(agents, capabilityCeiling) {
     const body = buildAdvertisedAgentCatalog(agents, capabilityCeiling);
     return body === undefined ? undefined : wrapAdvertisedAgentCatalog(body);
 }
-//# sourceMappingURL=advertised-agent-prompt.js.map

package/src/agents/agent-management.d.ts

@@ -25,4 +25,3 @@ export declare function handleCreate(params: ManagementParams, ctx: ManagementCo
 export declare function handleUpdate(params: ManagementParams, ctx: ManagementContext): AgentToolResult<Details>;
 export declare function handleManagementAction(action: string, params: ManagementParams, ctx: ManagementContext): AgentToolResult<Details>;
 export {};
-//# sourceMappingURL=agent-management.d.ts.map

package/src/agents/agent-management.js

@@ -1519,4 +1519,3 @@ export function handleManagementAction(action, params, ctx) {
         default: return result(`Unknown action: ${action}`, true);
     }
 }
-//# sourceMappingURL=agent-management.js.map

package/src/agents/agent-memory.d.ts

@@ -46,4 +46,3 @@ export declare function readMemoryFile(memoryDir: string): MemoryFileResult;
  */
 export declare function buildAgentMemoryInjection(agent: AgentConfig, cwd: string): string;
 export {};
-//# sourceMappingURL=agent-memory.d.ts.map

package/src/agents/agent-memory.js

@@ -346,4 +346,3 @@ export function buildAgentMemoryInjection(agent, cwd) {
         "---",
     ].join("\n");
 }
-//# sourceMappingURL=agent-memory.js.map

package/src/agents/agent-refinements.d.ts

@@ -97,4 +97,3 @@ export declare function handleRefinementAction(action: RefinementAction, params:
     agent?: string;
 }, ctx: RefinementActionContext): Promise<AgentToolResult<Details>>;
 export {};
-//# sourceMappingURL=agent-refinements.d.ts.map

package/src/agents/agent-refinements.js

@@ -566,4 +566,3 @@ export async function handleRefinementAction(action, params, ctx) {
         `Edits: ${validation.proposal.edits.length}`,
     ].join("\n"));
 }
-//# sourceMappingURL=agent-refinements.js.map

package/src/agents/agent-scope.d.ts

@@ -1,4 +1,3 @@
 import type { AgentScope } from "./agents.ts";
 export declare function resolveExecutionAgentScope(scope: unknown): AgentScope;
 export declare function projectScopeRequiresTrustMessage(cwd: string): string;
-//# sourceMappingURL=agent-scope.d.ts.map

package/src/agents/agent-scope.js

@@ -6,4 +6,3 @@ export function resolveExecutionAgentScope(scope) {
 export function projectScopeRequiresTrustMessage(cwd) {
     return `agentScope: "project" requires project trust. This session declined trust for ${cwd}, so project agents and project subagent settings are ignored. Re-run with agentScope: "user" or approve the project folder.`;
 }
-//# sourceMappingURL=agent-scope.js.map

package/src/agents/agent-selection.d.ts

@@ -1,3 +1,2 @@
 import type { AgentScope, AgentConfig } from "./agents.ts";
 export declare function mergeAgentsForScope(scope: AgentScope, userAgents: AgentConfig[], projectAgents: AgentConfig[], builtinAgents?: AgentConfig[], packageAgents?: AgentConfig[]): AgentConfig[];
-//# sourceMappingURL=agent-selection.d.ts.map

package/src/agents/agent-selection.js

@@ -20,4 +20,3 @@ export function mergeAgentsForScope(scope, userAgents, projectAgents, builtinAge
     }
     return Array.from(agentMap.values());
 }
-//# sourceMappingURL=agent-selection.js.map

package/src/agents/agent-serializer.d.ts

@@ -5,4 +5,3 @@ interface SerializeAgentOptions {
 }
 export declare function serializeAgent(config: AgentConfig, options?: SerializeAgentOptions): string;
 export {};
-//# sourceMappingURL=agent-serializer.d.ts.map

package/src/agents/agent-serializer.js

@@ -203,4 +203,3 @@ export function serializeAgent(config, options = {}) {
     const body = config.systemPrompt ?? "";
     return `${lines.join("\n")}\n\n${body}\n`;
 }
-//# sourceMappingURL=agent-serializer.js.map

package/src/agents/agents.d.ts

@@ -341,4 +341,3 @@ export declare function discoverAgentSnapshot(cwd: string, scope: AgentScope, pr
 }): AgentDiscoverySnapshot;
 export declare function discoverAgents(cwd: string, scope: AgentScope, preferredModelProvider?: string, options?: AgentDiscoveryOptions): AgentDiscoveryResult;
 export declare function discoverAgentsAll(cwd: string, preferredModelProvider?: string, options?: AgentDiscoveryOptions): AgentDiscoveryAllResult;
-//# sourceMappingURL=agents.d.ts.map

package/src/agents/agents.js

@@ -2745,4 +2745,3 @@ export function discoverAgents(cwd, scope, preferredModelProvider, options = {})
 export function discoverAgentsAll(cwd, preferredModelProvider, options = {}) {
     return discoverAgentSnapshot(cwd, "both", preferredModelProvider, options).all;
 }
-//# sourceMappingURL=agents.js.map

package/src/agents/builtin-names.d.ts

@@ -1,2 +1 @@
 export declare const BUILTIN_AGENT_NAMES: readonly ["advisor", "claude-code", "claude-code-writer", "codex-exec", "codex-exec-writer", "cursor-agent", "cursor-agent-writer", "delegate", "evidence-auditor", "oracle", "researcher", "reviewer", "scout", "worker"];
-//# sourceMappingURL=builtin-names.d.ts.map

package/src/agents/builtin-names.js

@@ -14,4 +14,3 @@ export const BUILTIN_AGENT_NAMES = [
     "scout",
     "worker",
 ];
-//# sourceMappingURL=builtin-names.js.map

package/src/agents/chain-serializer.d.ts

@@ -4,4 +4,3 @@ export declare function parseChain(content: string, source: AgentSource, filePat
 export declare function parseJsonChain(content: string, source: AgentSource, filePath: string): ChainConfig;
 export declare function serializeJsonChain(config: ChainConfig): string;
 export declare function serializeChain(config: ChainConfig): string;
-//# sourceMappingURL=chain-serializer.d.ts.map

package/src/agents/chain-serializer.js

@@ -316,4 +316,3 @@ export function serializeChain(config) {
     }
     return `${lines.join("\n")}\n`;
 }
-//# sourceMappingURL=chain-serializer.js.map

package/src/agents/frontmatter.d.ts

@@ -13,4 +13,3 @@ export declare function parseFrontmatter(content: string): {
     frontmatter: Record<string, string>;
     body: string;
 };
-//# sourceMappingURL=frontmatter.d.ts.map

package/src/agents/frontmatter.js

@@ -139,4 +139,3 @@ export function parseFrontmatter(content) {
     }
     return { frontmatter, body };
 }
-//# sourceMappingURL=frontmatter.js.map

package/src/agents/global-npm-root.d.ts

@@ -4,4 +4,3 @@ export declare function resolveGlobalNpmRoot(options?: {
     platform?: NodeJS.Platform;
     timeoutMs?: number;
 }): Promise<string | null>;
-//# sourceMappingURL=global-npm-root.d.ts.map

package/src/agents/global-npm-root.js

@@ -55,4 +55,3 @@ export async function resolveGlobalNpmRoot(options = {}) {
         return null;
     }
 }
-//# sourceMappingURL=global-npm-root.js.map

package/src/agents/identity.d.ts

@@ -5,4 +5,3 @@ export declare function parsePackageName(value: unknown, label?: string): {
 };
 export declare function buildRuntimeName(localName: string, packageName?: string): string;
 export declare function frontmatterNameForConfig(config: Pick<AgentConfig | ChainConfig, "name" | "localName" | "packageName">): string;
-//# sourceMappingURL=identity.d.ts.map

package/src/agents/identity.js

@@ -27,4 +27,3 @@ export function frontmatterNameForConfig(config) {
     }
     return config.name;
 }
-//# sourceMappingURL=identity.js.map

package/src/agents/proactive-skills.d.ts

@@ -33,4 +33,3 @@ export declare function buildProactiveSkillSubagentRecommendationLines(input: {
     config?: ProactiveSkillSubagentsConfig | false;
     discoverAvailableSkills: () => AvailableSkill[];
 }): string[];
-//# sourceMappingURL=proactive-skills.d.ts.map

package/src/agents/proactive-skills.js

@@ -153,4 +153,3 @@ export function buildProactiveSkillSubagentRecommendationLines(input) {
         ...(input.config !== undefined ? { config: input.config } : {}),
     }));
 }
-//# sourceMappingURL=proactive-skills.js.map

package/src/agents/runtime-agent-events.d.ts

@@ -24,4 +24,3 @@ export interface RegisterRuntimeAgentViaEventsInput {
 export declare function registerAgentViaEvents(input: RegisterRuntimeAgentViaEventsInput): RuntimeAgentRegistration;
 /** Install the process-local registration listener for the owning pi-subagents runtime. */
 export declare function registerRuntimeAgentEventListener(pi: ExtensionAPI): () => void;
-//# sourceMappingURL=runtime-agent-events.d.ts.map

package/src/agents/runtime-agent-events.js

@@ -50,4 +50,3 @@ export function registerRuntimeAgentEventListener(pi) {
         }
     });
 }
-//# sourceMappingURL=runtime-agent-events.js.map

package/src/agents/runtime-agent-registry.d.ts

@@ -61,4 +61,3 @@ export declare function mergeRuntimeAgents<T extends {
     agents: AgentConfig[];
     agentDiagnostics?: AgentDiscoveryDiagnostic[];
 }>(pi: RuntimeAgentOwner, discovered: T, configuredAgents?: readonly AgentConfig[], settings?: RuntimeAgentSettingsContext): T;
-//# sourceMappingURL=runtime-agent-registry.d.ts.map

package/src/agents/runtime-agent-registry.js

@@ -392,4 +392,3 @@ export function mergeRuntimeAgents(pi, discovered, configuredAgents = discovered
     const runtimeAgents = settings ? applyRuntimeAgentSettings(registered, settings) : registered;
     return { ...discovered, agents: [...discovered.agents, ...runtimeAgents] };
 }
-//# sourceMappingURL=runtime-agent-registry.js.map

package/src/agents/skills.d.ts

@@ -32,4 +32,3 @@ export declare function discoverAvailableSkills(cwd: string): Array<{
 }>;
 export declare function clearSkillCache(): void;
 export {};
-//# sourceMappingURL=skills.d.ts.map

package/src/agents/skills.js

@@ -715,4 +715,3 @@ export function clearSkillCache() {
     skillCache.clear();
     loadSkillsCache = null;
 }
-//# sourceMappingURL=skills.js.map

package/src/api/agents.d.ts

@@ -2,4 +2,3 @@ import type { RegisterRuntimeAgentInput, RuntimeAgentDefinition, RuntimeAgentReg
 export { registerRuntimeAgent as registerAgent } from "../agents/runtime-agent-registry.ts";
 export { RUNTIME_AGENT_REGISTER_EVENT, RUNTIME_AGENT_REGISTER_VERSION, registerAgentViaEvents, type RegisterRuntimeAgentViaEventsInput, type RuntimeAgentRegistrationRequest, type RuntimeAgentRegistrationResult, } from "../agents/runtime-agent-events.ts";
 export type { RegisterRuntimeAgentInput, RuntimeAgentDefinition, RuntimeAgentRegistration };
-//# sourceMappingURL=agents.d.ts.map

package/src/api/agents.js

@@ -1,3 +1,2 @@
 export { registerRuntimeAgent as registerAgent } from "../agents/runtime-agent-registry.js";
 export { RUNTIME_AGENT_REGISTER_EVENT, RUNTIME_AGENT_REGISTER_VERSION, registerAgentViaEvents, } from "../agents/runtime-agent-events.js";
-//# sourceMappingURL=agents.js.map

package/src/api/background-work.d.ts

@@ -36,4 +36,3 @@ export declare function listBackgroundWorkProviders(): readonly BackgroundWorkPr
 export declare function listBackgroundWorkWakeChannels(): readonly string[];
 /** Reconcile and snapshot active provider work owned by one exact Pi session. */
 export declare function snapshotBackgroundWork(sessionId: string, nowMs?: number): BackgroundWorkSnapshot;
-//# sourceMappingURL=background-work.d.ts.map

package/src/api/background-work.js

@@ -162,4 +162,3 @@ export function snapshotBackgroundWork(sessionId, nowMs = Date.now()) {
         items,
     };
 }
-//# sourceMappingURL=background-work.js.map

package/src/api/capability-ceiling.d.ts

@@ -1,2 +1 @@
 export { SUBAGENT_CAPABILITY_CEILING_REGISTRY_KEY, SUBAGENT_CAPABILITY_CEILING_VERSION, decodeSubagentCapabilityCeiling, encodeSubagentCapabilityCeiling, intersectSubagentCapabilityCeilings, parseSubagentCapabilityCeiling, registerSubagentCapabilityCeiling, resolveCurrentSubagentCapabilityCeiling, resolveSubagentCapabilityCeiling, type RegisterSubagentCapabilityCeilingOptions, type ResolvedSubagentCapabilityCeiling, type SubagentCapabilityCeiling, type SubagentCapabilityCeilingHandle, type SubagentCapabilityAudit, } from "../runs/shared/capability-ceiling.ts";
-//# sourceMappingURL=capability-ceiling.d.ts.map

package/src/api/capability-ceiling.js

@@ -1,2 +1 @@
 export { SUBAGENT_CAPABILITY_CEILING_REGISTRY_KEY, SUBAGENT_CAPABILITY_CEILING_VERSION, decodeSubagentCapabilityCeiling, encodeSubagentCapabilityCeiling, intersectSubagentCapabilityCeilings, parseSubagentCapabilityCeiling, registerSubagentCapabilityCeiling, resolveCurrentSubagentCapabilityCeiling, resolveSubagentCapabilityCeiling, } from "../runs/shared/capability-ceiling.js";
-//# sourceMappingURL=capability-ceiling.js.map

package/src/api/child-tool-plan.d.ts

@@ -1,2 +1 @@
 export { resolvePiLaunchToolPlan, type PiLaunchToolPlan, type ResolvePiLaunchToolPlanInput, } from "../runs/shared/child-tool-plan.ts";
-//# sourceMappingURL=child-tool-plan.d.ts.map

package/src/api/child-tool-plan.js

@@ -1,2 +1 @@
 export { resolvePiLaunchToolPlan, } from "../runs/shared/child-tool-plan.js";
-//# sourceMappingURL=child-tool-plan.js.map

package/src/api/control-channel.d.ts

@@ -1,2 +1 @@
 export { requestAsyncStop, type StopRequest, } from "../runs/background/control-channel.ts";
-//# sourceMappingURL=control-channel.d.ts.map

package/src/api/control-channel.js

@@ -1,2 +1 @@
 export { requestAsyncStop, } from "../runs/background/control-channel.js";
-//# sourceMappingURL=control-channel.js.map

package/src/api/delegation.d.ts

@@ -110,4 +110,3 @@ export interface SubagentDelegationInvalidResponse {
 export type SubagentDelegationResponse = SubagentDelegationTerminalResponse | SubagentDelegationInvalidResponse;
 export interface SubagentDelegationCancel extends SubagentDelegationStarted {
 }
-//# sourceMappingURL=delegation.d.ts.map

package/src/api/delegation.js

@@ -6,4 +6,3 @@ export const SUBAGENT_DELEGATION_STARTED_EVENT = "prompt-template:subagent:start
 export const SUBAGENT_DELEGATION_UPDATE_EVENT = "prompt-template:subagent:update";
 export const SUBAGENT_DELEGATION_RESPONSE_EVENT = "prompt-template:subagent:response";
 export const SUBAGENT_DELEGATION_CANCEL_EVENT = "prompt-template:subagent:cancel";
-//# sourceMappingURL=delegation.js.map

package/src/api/external-job-provider.d.ts

@@ -55,4 +55,3 @@ export declare function validateExternalJobResult(provider: string, value: unkno
 export declare function registerExternalJobProvider(provider: ExternalJobProvider): () => void;
 export declare function listExternalJobProviders(): readonly ExternalJobProvider[];
 export declare function getExternalJobProvider(name: string): ExternalJobProvider | undefined;
-//# sourceMappingURL=external-job-provider.d.ts.map

package/src/api/external-job-provider.js

@@ -137,4 +137,3 @@ export function getExternalJobProvider(name) {
     const safeName = validateString(name, "External-job provider name", MAX_PROVIDER_NAME_LENGTH);
     return listExternalJobProviders().find((provider) => provider.name === safeName);
 }
-//# sourceMappingURL=external-job-provider.js.map

package/src/api/external-runs.d.ts

@@ -45,4 +45,3 @@ export declare function unregisterExternalRun(sessionId: string, id: string): bo
 export declare function snapshotExternalRuns(sessionId: string, options?: ExternalRunSnapshotOptions): readonly ExternalRun[];
 /** Alias for callers that prefer list terminology. */
 export declare const listExternalRuns: typeof snapshotExternalRuns;
-//# sourceMappingURL=external-runs.d.ts.map

package/src/api/external-runs.js

@@ -243,4 +243,3 @@ export function snapshotExternalRuns(sessionId, options = {}) {
 }
 /** Alias for callers that prefer list terminology. */
 export const listExternalRuns = snapshotExternalRuns;
-//# sourceMappingURL=external-runs.js.map

package/src/api/inspectors.d.ts

@@ -18,4 +18,3 @@ export interface InspectorRegistrationRequest {
 }
 /** Register with the installed owner, even when each extension has its own module root. */
 export declare function registerInspector(pi: Pick<ExtensionAPI, "events">, plugin: InspectorPlugin): InspectorRegistration;
-//# sourceMappingURL=inspectors.d.ts.map

package/src/api/inspectors.js

@@ -9,4 +9,3 @@ export function registerInspector(pi, plugin) {
         throw request.result.error;
     return request.result.registration;
 }
-//# sourceMappingURL=inspectors.js.map

package/src/api/intercom-bridge.d.ts

@@ -1,2 +1 @@
 export { resolveIntercomSessionTarget, } from "../intercom/intercom-bridge.ts";
-//# sourceMappingURL=intercom-bridge.d.ts.map

package/src/api/intercom-bridge.js

@@ -1,2 +1 @@
 export { resolveIntercomSessionTarget, } from "../intercom/intercom-bridge.js";
-//# sourceMappingURL=intercom-bridge.js.map