@mutagent/cli 0.2.114 → 0.2.115

package/dist/bin/cli.js

@@ -22073,6 +22073,8 @@ Scopes are derived by the server from the entry, the stage and the entry's polic
 There is no grant flag to pass. Some writes never run from a sandbox: archiving an
 entry (\`factory delete\`) and, unless the policy allows it, the ship deploy call
 (see [workflows/factory-ship.md](../workflows/factory-ship.md)).
+A sandbox never launches another sandbox (\`mutagent helix agent …\`): the platform
+refuses it (\`SANDBOX_CANNOT_LAUNCH\`); a person starts one from a terminal, Desktop or the web.
 
 ## The session ends with a check
 
@@ -22080,7 +22082,7 @@ When a sandbox session ends, the platform checks its work: specs in sync, stage
 runs finished, reports pushed. If something is missing, the session is woken with
 the list and continues. Finish your runs and push your reports before you stop.
 `,
-  "workflows/agent-deployment.md": "# Managed agents: check, deploy and run an agent.md folder\n\nUse this journey when the user has an agent folder whose entry file is a\nlowercase `agent.md` (YAML frontmatter, then the standing prompt), optionally\nwith TypeScript tools, skill folders and files. Read `mutagent agent --help` and\nthe leaf's help before the first use; help owns the flags and the JSON shapes.\nThe CLI compiles the tools and packages the folder. Do not write registration\nglue or forward a path on this machine to the server.\n\nThe format, in one paragraph: `name` (the slug), `description`, `model`\n(`provider/model`, as `mutagent helix models` lists it), `thinking`, `tools`,\n`disallowed_tools` and `skills` are the local brief. Deployment settings sit in\none optional `harness:` block: `tools.builtin`, `tools.modules`, `skills`,\n`files`, `bindings.secrets`, `runtime.mode` (`interactive` or `headless`) and\n`runtime.scaffold` (`standard`). A deployed agent gets exactly the tools and\nskills `harness:` declares. `apiVersion`, `kind` and `metadata` are refused.\n\n1. **Check.** `mutagent agent check <agent.md> --json`. No network, no model call,\n   no tool code runs. Fix every diagnostic before going further.\n2. **Run locally, when the user wants to try it.**\n   `mutagent agent run <agent.md> \"<task>\" --json` runs the task with the local\n   Helix binary and this machine's LLM provider key. It is not isolated and\n   creates nothing in the workspace. It takes a file; a slug is refused.\n3. **Deploy.** `mutagent agent deploy <agent.md> [--env <name>] --json`. `--env`\n   names the slot (the agent in that Environment); without it the default slot\n   is used. One server-side operation validates and stores the package as the\n   next revision and activates it. The server refuses, before writing anything:\n   a model outside the workspace model list, an Environment the workspace lacks,\n   a required secret binding, an inline agent that already has the slug, and a\n   server with no sandbox provider that can stage a package. Report the message\n   as the server words it. Show `_directive.renderedCard` verbatim.\n   `--no-activate` stores the revision and leaves the slot on its active one.\n4. **Run the managed agent.**\n   `mutagent helix agent @<slug> [--env <name>] -p \"<task>\"` runs headless;\n   `--rpc` runs interactive. `@<slug>:vN` pins a revision; `@<slug>:latest` runs\n   the newest validated one. The receipt (reference, sessionId: the hs1_ session\n   id, agent, mode) is one JSON line on stderr: keep the reference. `mutagent helix session attach`,\n   `send` (interactive only), `signal`, `checkpoint`, `checkpoints` and\n   `close-input` take it. Restore of a managed agent's session is refused today;\n   start a new run.\n5. **Inspect.** `mutagent agent inspect <slug> [--env <name>] --json` shows the\n   revisions, each slot's active revision and the sessions launched from it.\n   `mutagent agent list --json` lists the workspace's managed agents.\n6. **Roll back or retire.** `mutagent agent activate <slug> --revision vN\n   [--env <name>] --json` makes an older revision active for new runs; running\n   sessions keep theirs. `mutagent agent retire <slug> [--env <name>] --force`\n   disables the slot; `activate` re-enables it. Retire refuses without `--force`\n   in every mode: confirm with the user first.\n\nOn an uncertain deploy or activate (a network error, a 5xx), retry the same\ncommand with the same `--idempotency-key` the error's recovery names; a new key\nis a new request. `mutagent agent inspect --operation <id>` shows the recorded\noutcome of one operation. `pack --output <archive>` writes the archive for\ninspection; the path must be outside the agent folder and replacing a file\nneeds `--force`.\n",
+  "workflows/agent-deployment.md": "# Managed agents: check, deploy and run an agent.md folder\n\nUse this journey when the user has an agent folder whose entry file is a\nlowercase `agent.md` (YAML frontmatter, then the standing prompt), optionally\nwith TypeScript tools, skill folders and files. Read `mutagent agent --help` and\nthe leaf's help before the first use; help owns the flags and the JSON shapes.\nThe CLI compiles the tools and packages the folder. Do not write registration\nglue or forward a path on this machine to the server.\n\nThe format, in one paragraph: `name` (the slug), `description`, `model`\n(`provider/model`, as `mutagent helix models` lists it), `thinking`, `tools`,\n`disallowed_tools` and `skills` are the local brief. Deployment settings sit in\none optional `harness:` block: `tools.builtin`, `tools.modules`, `skills`,\n`files`, `bindings.secrets`, `runtime.mode` (`interactive` or `headless`) and\n`runtime.scaffold` (`standard`). A deployed agent gets exactly the tools and\nskills `harness:` declares. `apiVersion`, `kind` and `metadata` are refused.\n\n1. **Check.** `mutagent agent check <agent.md> --json`. No network, no model call,\n   no tool code runs. Fix every diagnostic before going further.\n2. **Run locally, when the user wants to try it.**\n   `mutagent agent run <agent.md> \"<task>\" --json` runs the task with the local\n   Helix binary and this machine's LLM provider key. It is not isolated and\n   creates nothing in the workspace. It takes a file; a slug is refused.\n3. **Deploy.** `mutagent agent deploy <agent.md> [--env <name>] --json`. `--env`\n   names the slot (the agent in that Environment); without it the default slot\n   is used. One server-side operation validates and stores the package as the\n   next revision and activates it. The server refuses, before writing anything:\n   a model outside the workspace model list, an Environment the workspace lacks,\n   a required secret binding, an inline agent that already has the slug, and a\n   server with no sandbox provider that can stage a package. Report the message\n   as the server words it. Show `_directive.renderedCard` verbatim.\n   `--no-activate` stores the revision and leaves the slot on its active one.\n4. **Run the managed agent.**\n   `mutagent helix agent @<slug> [--env <name>] -p \"<task>\"` runs headless;\n   `--rpc` runs interactive. `@<slug>:vN` pins a revision; `@<slug>:latest` runs\n   the newest validated one. The receipt (reference, sessionId: the hs1_ session\n   id, agent, mode) is one JSON line on stderr: keep the reference. `mutagent helix session attach`,\n   `send` (interactive only), `signal`, `checkpoint`, `checkpoints` and\n   `close-input` take it. Restore of a managed agent's session is refused today;\n   start a new run. A person starts a managed agent run (terminal, Desktop, web); from inside a\n   cloud sandbox the platform refuses the launch (`SANDBOX_CANNOT_LAUNCH`): show the refusal as-is.\n5. **Inspect.** `mutagent agent inspect <slug> [--env <name>] --json` shows the\n   revisions, each slot's active revision and the sessions launched from it.\n   `mutagent agent list --json` lists the workspace's managed agents.\n6. **Roll back or retire.** `mutagent agent activate <slug> --revision vN\n   [--env <name>] --json` makes an older revision active for new runs; running\n   sessions keep theirs. `mutagent agent retire <slug> [--env <name>] --force`\n   disables the slot; `activate` re-enables it. Retire refuses without `--force`\n   in every mode: confirm with the user first.\n\nOn an uncertain deploy or activate (a network error, a 5xx), retry the same\ncommand with the same `--idempotency-key` the error's recovery names; a new key\nis a new request. `mutagent agent inspect --operation <id>` shows the recorded\noutcome of one operation. `pack --output <archive>` writes the archive for\ninspection; the path must be outside the agent folder and replacing a file\nneeds `--force`.\n",
   "workflows/factory-register.md": `---
 name: mutagent-cli-workflows-factory-register
 description: |
@@ -22307,10 +22309,12 @@ user confirms). Locally, record it as in P4. In a cloud sandbox:
 3. **Finish the run:** \`mutagent factory stage finish --state succeeded --verdict PASS --json\`.
 4. A session ending with work missing is woken with the list.
 
-**Only when the user asks for a separate sandbox:**
+**Only when the user asks for a separate sandbox, and never from inside a sandbox:**
 \`mutagent helix agent --name <agent> --subject <entry-id> --stage <stage> -p "<task>"\`
 starts a visible child session (\`mutagent helix session list\`, the web); its agent
 finishes the run the platform opens. Follow it: \`mutagent factory stage show <run-id>\`.
+A person starts it from a terminal, Desktop or the web. In a cloud sandbox the platform
+refuses it (\`SANDBOX_CANNOT_LAUNCH\`, 403): show the refusal as-is and run the stage here instead.
 Never run a stage in a local child process: no one could see it.
 
 ## P4: record a stage that ran locally
@@ -40512,4 +40516,4 @@ if (process.env.CLI_VERSION) {
 }
 runCli(process.argv.slice(2), cliVersion);
 
-//# debugId=7C028E2C751B9AA164756E2164756E21
+//# debugId=21A90EDDA00A444E64756E2164756E21

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@mutagent/cli",
-  "version": "0.2.114",
+  "version": "0.2.115",
   "description": "Bun-native CLI for the MutagenT AI platform - auth, provider config, and lifecycle-tool installer for AI-native workflows",
   "type": "module",
   "bin": {