sandboxedjs 0.2.22 → 0.2.23

package/dist/agent.cjs

@@ -356,6 +356,8 @@ host machine you can reach. Everything below is real and available to you.
   container.
 - A virtual network stack. Servers you start inside the container really listen
   on their ports and can really be requested.
+- A machine-readable inventory. Run \`sandboxedjs-capabilities --json\` before
+  planning an unfamiliar workflow instead of guessing what the runtime has.
 
 ## What you do not have
 
@@ -391,33 +393,37 @@ the user receives and what a preview will serve. Write real, complete files to
 real paths \u2014 do not print a project to stdout and call it done.`;
 var SANDBOX_AGENT_RULES = `# Rules
 
-1. Verify before you claim. If you say a server runs or a build passes, you
+1. For an unfamiliar task, inspect \`sandboxedjs-capabilities --json\`, the
+   workspace, and relevant command help. Work backward from the requested
+   outcome and compose a workflow from capabilities that are actually present.
+2. Verify before you claim. If you say a server runs or a build passes, you
    ran it in this container and read the output. Never report success you have
    not observed.
-2. One command, one purpose. Chain with \`&&\` when steps depend on each other
+3. One command, one purpose. Chain with \`&&\` when steps depend on each other
    so a failure stops the chain instead of hiding under a later success.
-3. Read a file before editing it. Edits are literal string replacements; they
+4. Read a file before editing it. Edits are literal string replacements; they
    fail when you are guessing at the current contents.
-4. Use absolute paths in file tools. Use \`cd\` inside a single shell command
+5. Use absolute paths in file tools. Use \`cd\` inside a single shell command
    when a command needs a working directory.
-5. Install dependencies with \`npm install <pkg>\`, in the directory that has
+6. Install dependencies with \`npm install <pkg>\`, in the directory that has
    the \`package.json\`. Do not hand-write \`node_modules\` or invent versions
    in \`package.json\` \u2014 let the installer resolve them.
-6. Background every server and long task, redirect its output to a log file,
+7. Background every server and long task, redirect its output to a log file,
    then poll the log. Never leave a command running in the foreground.
-7. Keep command output small. Pipe noisy commands through \`tail\`, \`head\`
+8. Keep command output small. Pipe noisy commands through \`tail\`, \`head\`
    or \`grep\`. Output is truncated past the backend's limit and you will lose
    the part you needed.
-8. When a command fails, read stderr and fix the cause. Do not retry the same
-   command unchanged, and do not work around a failure by faking its result.
-9. Prefer the project's own tooling \u2014 \`npm run build\`, \`npm test\`,
-   \`npx vite\` \u2014 over reimplementing what it already does.
-10. Do not attempt to escape the container, reach the host, or disable the
+9. When a command fails, read stderr, update the workflow, and use another
+   available capability when appropriate. Do not retry the same command
+   unchanged, and do not work around a failure by faking its result.
+10. Prefer the project's own tooling \u2014 \`npm run build\`, \`npm test\`,
+    \`npx vite\` \u2014 over reimplementing what it already does.
+11. Do not attempt to escape the container, reach the host, or disable the
     network policy. Outbound access is the host's decision, not yours.
-11. Prefer the non-interactive form of a command when one exists \u2014 pass the
+12. Prefer the non-interactive form of a command when one exists \u2014 pass the
     flags that pre-answer its questions. A generator that asks nothing is
     faster and its result is the same every run.
-12. An interactive prompt is not a failure. If a command stops on a question
+13. An interactive prompt is not a failure. If a command stops on a question
     or a menu, answer it: send the text, or the arrow keys and Enter that the
     prompt names. Read what is on screen before answering, and do not send a
     second answer until the screen has changed.`;

package/dist/agent.d.cts

@@ -1,5 +1,5 @@
-import { C as Container } from './container-BQx27_d-.cjs';
-import './contracts-BHo4LdY2.cjs';
+import { C as Container } from './container-CPwPlvmB.cjs';
+import './contracts-BFG82pSs.cjs';
 
 /**
  * Structural copies of the LangChain Deep Agents backend contract.
@@ -167,14 +167,14 @@ declare class SandboxedJsBackend implements SandboxBackendProtocolV2 {
  * `docker`, `sudo`, `systemctl`, `curl localhost:3000`, or a background process
  * that outlives the turn. Saying plainly what exists is what stops that.
  */
-declare const SANDBOX_ENVIRONMENT_PROMPT = "# Your environment\n\nYou are working inside a sandboxedjs container: a Linux-like environment that\nruns entirely inside a JavaScript process. There is no Docker, no VM, and no\nhost machine you can reach. Everything below is real and available to you.\n\n## What you have\n\n- A POSIX shell (`sh`/`bash` syntax): pipes, redirection, `&&`, `||`,\n  subshells, globs, heredocs, variables, functions, `for`/`while`/`case`.\n- Around 140 coreutils: `ls cat cp mv rm mkdir find grep sed awk head tail\n  sort uniq wc diff patch tar gzip curl chmod ln touch echo printf test` and\n  the rest of the usual set.\n- Node.js, with `node`, `npm` and `npx`. `npm install` resolves against\n  the real npm registry when outbound network is enabled.\n- Python 3 via `python3` and `pip`, when the host enabled the Python runtime.\n- A writable virtual filesystem rooted at `/`, persistent for the life of the\n  container.\n- A virtual network stack. Servers you start inside the container really listen\n  on their ports and can really be requested.\n\n## What you do not have\n\n- No Docker, no VM, no `systemctl`, no `service`, no `apt`/`apt-get`,\n  no `yum`, no `brew`. Never try to install system packages.\n- No `sudo` and no reason for it: you already run as the container's user and\n  the filesystem is yours.\n- No access to the host machine, its files, its network interfaces, or its\n  environment variables. Nothing outside the container exists for you.\n- No GUI, no browser, no interactive editors. Do not run `vim`, `nano`,\n  `less`, or `top`; they will hang or fail. Read files by reading them and\n  edit them by editing them.\n- No long-running foreground commands. A command that never exits will hit the\n  execution timeout and the turn is wasted.\n\n## Running servers\n\nStart servers in the background and never block on them:\n\n```sh\nnode server.js > /tmp/server.log 2>&1 &\n```\n\nThen poll the log for readiness rather than requesting the port immediately.\nDo not run a dev server in the foreground. Do not use `curl localhost:PORT`\nto prove a server works unless you started it in the background first \u2014 the\nhost, not you, is the one that will connect to it.\n\n## How your work is used\n\nThe container is the deliverable. Files you write to the filesystem are what\nthe user receives and what a preview will serve. Write real, complete files to\nreal paths \u2014 do not print a project to stdout and call it done.";
+declare const SANDBOX_ENVIRONMENT_PROMPT = "# Your environment\n\nYou are working inside a sandboxedjs container: a Linux-like environment that\nruns entirely inside a JavaScript process. There is no Docker, no VM, and no\nhost machine you can reach. Everything below is real and available to you.\n\n## What you have\n\n- A POSIX shell (`sh`/`bash` syntax): pipes, redirection, `&&`, `||`,\n  subshells, globs, heredocs, variables, functions, `for`/`while`/`case`.\n- Around 140 coreutils: `ls cat cp mv rm mkdir find grep sed awk head tail\n  sort uniq wc diff patch tar gzip curl chmod ln touch echo printf test` and\n  the rest of the usual set.\n- Node.js, with `node`, `npm` and `npx`. `npm install` resolves against\n  the real npm registry when outbound network is enabled.\n- Python 3 via `python3` and `pip`, when the host enabled the Python runtime.\n- A writable virtual filesystem rooted at `/`, persistent for the life of the\n  container.\n- A virtual network stack. Servers you start inside the container really listen\n  on their ports and can really be requested.\n- A machine-readable inventory. Run `sandboxedjs-capabilities --json` before\n  planning an unfamiliar workflow instead of guessing what the runtime has.\n\n## What you do not have\n\n- No Docker, no VM, no `systemctl`, no `service`, no `apt`/`apt-get`,\n  no `yum`, no `brew`. Never try to install system packages.\n- No `sudo` and no reason for it: you already run as the container's user and\n  the filesystem is yours.\n- No access to the host machine, its files, its network interfaces, or its\n  environment variables. Nothing outside the container exists for you.\n- No GUI, no browser, no interactive editors. Do not run `vim`, `nano`,\n  `less`, or `top`; they will hang or fail. Read files by reading them and\n  edit them by editing them.\n- No long-running foreground commands. A command that never exits will hit the\n  execution timeout and the turn is wasted.\n\n## Running servers\n\nStart servers in the background and never block on them:\n\n```sh\nnode server.js > /tmp/server.log 2>&1 &\n```\n\nThen poll the log for readiness rather than requesting the port immediately.\nDo not run a dev server in the foreground. Do not use `curl localhost:PORT`\nto prove a server works unless you started it in the background first \u2014 the\nhost, not you, is the one that will connect to it.\n\n## How your work is used\n\nThe container is the deliverable. Files you write to the filesystem are what\nthe user receives and what a preview will serve. Write real, complete files to\nreal paths \u2014 do not print a project to stdout and call it done.";
 /**
  * Operating rules, in the register a coding harness uses.
  *
  * Deliberately about this environment rather than about coding in general: the
  * host's own system prompt owns the latter, and repeating it only dilutes both.
  */
-declare const SANDBOX_AGENT_RULES = "# Rules\n\n1. Verify before you claim. If you say a server runs or a build passes, you\n   ran it in this container and read the output. Never report success you have\n   not observed.\n2. One command, one purpose. Chain with `&&` when steps depend on each other\n   so a failure stops the chain instead of hiding under a later success.\n3. Read a file before editing it. Edits are literal string replacements; they\n   fail when you are guessing at the current contents.\n4. Use absolute paths in file tools. Use `cd` inside a single shell command\n   when a command needs a working directory.\n5. Install dependencies with `npm install <pkg>`, in the directory that has\n   the `package.json`. Do not hand-write `node_modules` or invent versions\n   in `package.json` \u2014 let the installer resolve them.\n6. Background every server and long task, redirect its output to a log file,\n   then poll the log. Never leave a command running in the foreground.\n7. Keep command output small. Pipe noisy commands through `tail`, `head`\n   or `grep`. Output is truncated past the backend's limit and you will lose\n   the part you needed.\n8. When a command fails, read stderr and fix the cause. Do not retry the same\n   command unchanged, and do not work around a failure by faking its result.\n9. Prefer the project's own tooling \u2014 `npm run build`, `npm test`,\n   `npx vite` \u2014 over reimplementing what it already does.\n10. Do not attempt to escape the container, reach the host, or disable the\n    network policy. Outbound access is the host's decision, not yours.\n11. Prefer the non-interactive form of a command when one exists \u2014 pass the\n    flags that pre-answer its questions. A generator that asks nothing is\n    faster and its result is the same every run.\n12. An interactive prompt is not a failure. If a command stops on a question\n    or a menu, answer it: send the text, or the arrow keys and Enter that the\n    prompt names. Read what is on screen before answering, and do not send a\n    second answer until the screen has changed.";
+declare const SANDBOX_AGENT_RULES = "# Rules\n\n1. For an unfamiliar task, inspect `sandboxedjs-capabilities --json`, the\n   workspace, and relevant command help. Work backward from the requested\n   outcome and compose a workflow from capabilities that are actually present.\n2. Verify before you claim. If you say a server runs or a build passes, you\n   ran it in this container and read the output. Never report success you have\n   not observed.\n3. One command, one purpose. Chain with `&&` when steps depend on each other\n   so a failure stops the chain instead of hiding under a later success.\n4. Read a file before editing it. Edits are literal string replacements; they\n   fail when you are guessing at the current contents.\n5. Use absolute paths in file tools. Use `cd` inside a single shell command\n   when a command needs a working directory.\n6. Install dependencies with `npm install <pkg>`, in the directory that has\n   the `package.json`. Do not hand-write `node_modules` or invent versions\n   in `package.json` \u2014 let the installer resolve them.\n7. Background every server and long task, redirect its output to a log file,\n   then poll the log. Never leave a command running in the foreground.\n8. Keep command output small. Pipe noisy commands through `tail`, `head`\n   or `grep`. Output is truncated past the backend's limit and you will lose\n   the part you needed.\n9. When a command fails, read stderr, update the workflow, and use another\n   available capability when appropriate. Do not retry the same command\n   unchanged, and do not work around a failure by faking its result.\n10. Prefer the project's own tooling \u2014 `npm run build`, `npm test`,\n    `npx vite` \u2014 over reimplementing what it already does.\n11. Do not attempt to escape the container, reach the host, or disable the\n    network policy. Outbound access is the host's decision, not yours.\n12. Prefer the non-interactive form of a command when one exists \u2014 pass the\n    flags that pre-answer its questions. A generator that asks nothing is\n    faster and its result is the same every run.\n13. An interactive prompt is not a failure. If a command stops on a question\n    or a menu, answer it: send the text, or the arrow keys and Enter that the\n    prompt names. Read what is on screen before answering, and do not send a\n    second answer until the screen has changed.";
 /** A Deep Agents skill: markdown with the frontmatter its loader parses. */
 interface SandboxSkill {
     name: string;

package/dist/agent.d.ts

@@ -1,5 +1,5 @@
-import { C as Container } from './container-D-e5SMXQ.js';
-import './contracts-BHo4LdY2.js';
+import { C as Container } from './container-DZabLWLy.js';
+import './contracts-BFG82pSs.js';
 
 /**
  * Structural copies of the LangChain Deep Agents backend contract.
@@ -167,14 +167,14 @@ declare class SandboxedJsBackend implements SandboxBackendProtocolV2 {
  * `docker`, `sudo`, `systemctl`, `curl localhost:3000`, or a background process
  * that outlives the turn. Saying plainly what exists is what stops that.
  */
-declare const SANDBOX_ENVIRONMENT_PROMPT = "# Your environment\n\nYou are working inside a sandboxedjs container: a Linux-like environment that\nruns entirely inside a JavaScript process. There is no Docker, no VM, and no\nhost machine you can reach. Everything below is real and available to you.\n\n## What you have\n\n- A POSIX shell (`sh`/`bash` syntax): pipes, redirection, `&&`, `||`,\n  subshells, globs, heredocs, variables, functions, `for`/`while`/`case`.\n- Around 140 coreutils: `ls cat cp mv rm mkdir find grep sed awk head tail\n  sort uniq wc diff patch tar gzip curl chmod ln touch echo printf test` and\n  the rest of the usual set.\n- Node.js, with `node`, `npm` and `npx`. `npm install` resolves against\n  the real npm registry when outbound network is enabled.\n- Python 3 via `python3` and `pip`, when the host enabled the Python runtime.\n- A writable virtual filesystem rooted at `/`, persistent for the life of the\n  container.\n- A virtual network stack. Servers you start inside the container really listen\n  on their ports and can really be requested.\n\n## What you do not have\n\n- No Docker, no VM, no `systemctl`, no `service`, no `apt`/`apt-get`,\n  no `yum`, no `brew`. Never try to install system packages.\n- No `sudo` and no reason for it: you already run as the container's user and\n  the filesystem is yours.\n- No access to the host machine, its files, its network interfaces, or its\n  environment variables. Nothing outside the container exists for you.\n- No GUI, no browser, no interactive editors. Do not run `vim`, `nano`,\n  `less`, or `top`; they will hang or fail. Read files by reading them and\n  edit them by editing them.\n- No long-running foreground commands. A command that never exits will hit the\n  execution timeout and the turn is wasted.\n\n## Running servers\n\nStart servers in the background and never block on them:\n\n```sh\nnode server.js > /tmp/server.log 2>&1 &\n```\n\nThen poll the log for readiness rather than requesting the port immediately.\nDo not run a dev server in the foreground. Do not use `curl localhost:PORT`\nto prove a server works unless you started it in the background first \u2014 the\nhost, not you, is the one that will connect to it.\n\n## How your work is used\n\nThe container is the deliverable. Files you write to the filesystem are what\nthe user receives and what a preview will serve. Write real, complete files to\nreal paths \u2014 do not print a project to stdout and call it done.";
+declare const SANDBOX_ENVIRONMENT_PROMPT = "# Your environment\n\nYou are working inside a sandboxedjs container: a Linux-like environment that\nruns entirely inside a JavaScript process. There is no Docker, no VM, and no\nhost machine you can reach. Everything below is real and available to you.\n\n## What you have\n\n- A POSIX shell (`sh`/`bash` syntax): pipes, redirection, `&&`, `||`,\n  subshells, globs, heredocs, variables, functions, `for`/`while`/`case`.\n- Around 140 coreutils: `ls cat cp mv rm mkdir find grep sed awk head tail\n  sort uniq wc diff patch tar gzip curl chmod ln touch echo printf test` and\n  the rest of the usual set.\n- Node.js, with `node`, `npm` and `npx`. `npm install` resolves against\n  the real npm registry when outbound network is enabled.\n- Python 3 via `python3` and `pip`, when the host enabled the Python runtime.\n- A writable virtual filesystem rooted at `/`, persistent for the life of the\n  container.\n- A virtual network stack. Servers you start inside the container really listen\n  on their ports and can really be requested.\n- A machine-readable inventory. Run `sandboxedjs-capabilities --json` before\n  planning an unfamiliar workflow instead of guessing what the runtime has.\n\n## What you do not have\n\n- No Docker, no VM, no `systemctl`, no `service`, no `apt`/`apt-get`,\n  no `yum`, no `brew`. Never try to install system packages.\n- No `sudo` and no reason for it: you already run as the container's user and\n  the filesystem is yours.\n- No access to the host machine, its files, its network interfaces, or its\n  environment variables. Nothing outside the container exists for you.\n- No GUI, no browser, no interactive editors. Do not run `vim`, `nano`,\n  `less`, or `top`; they will hang or fail. Read files by reading them and\n  edit them by editing them.\n- No long-running foreground commands. A command that never exits will hit the\n  execution timeout and the turn is wasted.\n\n## Running servers\n\nStart servers in the background and never block on them:\n\n```sh\nnode server.js > /tmp/server.log 2>&1 &\n```\n\nThen poll the log for readiness rather than requesting the port immediately.\nDo not run a dev server in the foreground. Do not use `curl localhost:PORT`\nto prove a server works unless you started it in the background first \u2014 the\nhost, not you, is the one that will connect to it.\n\n## How your work is used\n\nThe container is the deliverable. Files you write to the filesystem are what\nthe user receives and what a preview will serve. Write real, complete files to\nreal paths \u2014 do not print a project to stdout and call it done.";
 /**
  * Operating rules, in the register a coding harness uses.
  *
  * Deliberately about this environment rather than about coding in general: the
  * host's own system prompt owns the latter, and repeating it only dilutes both.
  */
-declare const SANDBOX_AGENT_RULES = "# Rules\n\n1. Verify before you claim. If you say a server runs or a build passes, you\n   ran it in this container and read the output. Never report success you have\n   not observed.\n2. One command, one purpose. Chain with `&&` when steps depend on each other\n   so a failure stops the chain instead of hiding under a later success.\n3. Read a file before editing it. Edits are literal string replacements; they\n   fail when you are guessing at the current contents.\n4. Use absolute paths in file tools. Use `cd` inside a single shell command\n   when a command needs a working directory.\n5. Install dependencies with `npm install <pkg>`, in the directory that has\n   the `package.json`. Do not hand-write `node_modules` or invent versions\n   in `package.json` \u2014 let the installer resolve them.\n6. Background every server and long task, redirect its output to a log file,\n   then poll the log. Never leave a command running in the foreground.\n7. Keep command output small. Pipe noisy commands through `tail`, `head`\n   or `grep`. Output is truncated past the backend's limit and you will lose\n   the part you needed.\n8. When a command fails, read stderr and fix the cause. Do not retry the same\n   command unchanged, and do not work around a failure by faking its result.\n9. Prefer the project's own tooling \u2014 `npm run build`, `npm test`,\n   `npx vite` \u2014 over reimplementing what it already does.\n10. Do not attempt to escape the container, reach the host, or disable the\n    network policy. Outbound access is the host's decision, not yours.\n11. Prefer the non-interactive form of a command when one exists \u2014 pass the\n    flags that pre-answer its questions. A generator that asks nothing is\n    faster and its result is the same every run.\n12. An interactive prompt is not a failure. If a command stops on a question\n    or a menu, answer it: send the text, or the arrow keys and Enter that the\n    prompt names. Read what is on screen before answering, and do not send a\n    second answer until the screen has changed.";
+declare const SANDBOX_AGENT_RULES = "# Rules\n\n1. For an unfamiliar task, inspect `sandboxedjs-capabilities --json`, the\n   workspace, and relevant command help. Work backward from the requested\n   outcome and compose a workflow from capabilities that are actually present.\n2. Verify before you claim. If you say a server runs or a build passes, you\n   ran it in this container and read the output. Never report success you have\n   not observed.\n3. One command, one purpose. Chain with `&&` when steps depend on each other\n   so a failure stops the chain instead of hiding under a later success.\n4. Read a file before editing it. Edits are literal string replacements; they\n   fail when you are guessing at the current contents.\n5. Use absolute paths in file tools. Use `cd` inside a single shell command\n   when a command needs a working directory.\n6. Install dependencies with `npm install <pkg>`, in the directory that has\n   the `package.json`. Do not hand-write `node_modules` or invent versions\n   in `package.json` \u2014 let the installer resolve them.\n7. Background every server and long task, redirect its output to a log file,\n   then poll the log. Never leave a command running in the foreground.\n8. Keep command output small. Pipe noisy commands through `tail`, `head`\n   or `grep`. Output is truncated past the backend's limit and you will lose\n   the part you needed.\n9. When a command fails, read stderr, update the workflow, and use another\n   available capability when appropriate. Do not retry the same command\n   unchanged, and do not work around a failure by faking its result.\n10. Prefer the project's own tooling \u2014 `npm run build`, `npm test`,\n    `npx vite` \u2014 over reimplementing what it already does.\n11. Do not attempt to escape the container, reach the host, or disable the\n    network policy. Outbound access is the host's decision, not yours.\n12. Prefer the non-interactive form of a command when one exists \u2014 pass the\n    flags that pre-answer its questions. A generator that asks nothing is\n    faster and its result is the same every run.\n13. An interactive prompt is not a failure. If a command stops on a question\n    or a menu, answer it: send the text, or the arrow keys and Enter that the\n    prompt names. Read what is on screen before answering, and do not send a\n    second answer until the screen has changed.";
 /** A Deep Agents skill: markdown with the frontmatter its loader parses. */
 interface SandboxSkill {
     name: string;

package/dist/agent.js

@@ -354,6 +354,8 @@ host machine you can reach. Everything below is real and available to you.
   container.
 - A virtual network stack. Servers you start inside the container really listen
   on their ports and can really be requested.
+- A machine-readable inventory. Run \`sandboxedjs-capabilities --json\` before
+  planning an unfamiliar workflow instead of guessing what the runtime has.
 
 ## What you do not have
 
@@ -389,33 +391,37 @@ the user receives and what a preview will serve. Write real, complete files to
 real paths \u2014 do not print a project to stdout and call it done.`;
 var SANDBOX_AGENT_RULES = `# Rules
 
-1. Verify before you claim. If you say a server runs or a build passes, you
+1. For an unfamiliar task, inspect \`sandboxedjs-capabilities --json\`, the
+   workspace, and relevant command help. Work backward from the requested
+   outcome and compose a workflow from capabilities that are actually present.
+2. Verify before you claim. If you say a server runs or a build passes, you
    ran it in this container and read the output. Never report success you have
    not observed.
-2. One command, one purpose. Chain with \`&&\` when steps depend on each other
+3. One command, one purpose. Chain with \`&&\` when steps depend on each other
    so a failure stops the chain instead of hiding under a later success.
-3. Read a file before editing it. Edits are literal string replacements; they
+4. Read a file before editing it. Edits are literal string replacements; they
    fail when you are guessing at the current contents.
-4. Use absolute paths in file tools. Use \`cd\` inside a single shell command
+5. Use absolute paths in file tools. Use \`cd\` inside a single shell command
    when a command needs a working directory.
-5. Install dependencies with \`npm install <pkg>\`, in the directory that has
+6. Install dependencies with \`npm install <pkg>\`, in the directory that has
    the \`package.json\`. Do not hand-write \`node_modules\` or invent versions
    in \`package.json\` \u2014 let the installer resolve them.
-6. Background every server and long task, redirect its output to a log file,
+7. Background every server and long task, redirect its output to a log file,
    then poll the log. Never leave a command running in the foreground.
-7. Keep command output small. Pipe noisy commands through \`tail\`, \`head\`
+8. Keep command output small. Pipe noisy commands through \`tail\`, \`head\`
    or \`grep\`. Output is truncated past the backend's limit and you will lose
    the part you needed.
-8. When a command fails, read stderr and fix the cause. Do not retry the same
-   command unchanged, and do not work around a failure by faking its result.
-9. Prefer the project's own tooling \u2014 \`npm run build\`, \`npm test\`,
-   \`npx vite\` \u2014 over reimplementing what it already does.
-10. Do not attempt to escape the container, reach the host, or disable the
+9. When a command fails, read stderr, update the workflow, and use another
+   available capability when appropriate. Do not retry the same command
+   unchanged, and do not work around a failure by faking its result.
+10. Prefer the project's own tooling \u2014 \`npm run build\`, \`npm test\`,
+    \`npx vite\` \u2014 over reimplementing what it already does.
+11. Do not attempt to escape the container, reach the host, or disable the
     network policy. Outbound access is the host's decision, not yours.
-11. Prefer the non-interactive form of a command when one exists \u2014 pass the
+12. Prefer the non-interactive form of a command when one exists \u2014 pass the
     flags that pre-answer its questions. A generator that asks nothing is
     faster and its result is the same every run.
-12. An interactive prompt is not a failure. If a command stops on a question
+13. An interactive prompt is not a failure. If a command stops on a question
     or a menu, answer it: send the text, or the arrow keys and Enter that the
     prompt names. Read what is on screen before answering, and do not send a
     second answer until the screen has changed.`;

package/dist/{container-D-e5SMXQ.d.ts → container-CPwPlvmB.d.cts}

@@ -1,4 +1,4 @@
-import { V as Vfs, C as Cred, f as RuntimePod, O as OutboundPolicy, D as DirEntry, p as Stats } from './contracts-BHo4LdY2.js';
+import { V as Vfs, C as Cred, q as SealedSecrets, f as RuntimePod, O as OutboundPolicy, D as DirEntry, r as Stats } from './contracts-BFG82pSs.cjs';
 
 /**
  * Byte streams for stdin/stdout/stderr, pipelines and redirections.
@@ -481,6 +481,14 @@ interface NetworkOptions {
      * proxy widens what a page can reach, not what the container may.
      */
     proxy?: string;
+    /**
+     * Sealed secrets: credentials a guest program may use but never read.
+     *
+     * A program writes `{{secret:NAME}}` in a request header; the value is put
+     * in as the request leaves, only for the hosts listed, and removed from the
+     * response. It is never written to the filesystem or the environment.
+     */
+    secrets?: SealedSecrets;
     /** Address handed to eth0. */
     ipv4?: string;
     gateway?: string;

package/dist/{container-BQx27_d-.d.cts → container-DZabLWLy.d.ts}

@@ -1,4 +1,4 @@
-import { V as Vfs, C as Cred, f as RuntimePod, O as OutboundPolicy, D as DirEntry, p as Stats } from './contracts-BHo4LdY2.cjs';
+import { V as Vfs, C as Cred, q as SealedSecrets, f as RuntimePod, O as OutboundPolicy, D as DirEntry, r as Stats } from './contracts-BFG82pSs.js';
 
 /**
  * Byte streams for stdin/stdout/stderr, pipelines and redirections.
@@ -481,6 +481,14 @@ interface NetworkOptions {
      * proxy widens what a page can reach, not what the container may.
      */
     proxy?: string;
+    /**
+     * Sealed secrets: credentials a guest program may use but never read.
+     *
+     * A program writes `{{secret:NAME}}` in a request header; the value is put
+     * in as the request leaves, only for the hosts listed, and removed from the
+     * response. It is never written to the filesystem or the environment.
+     */
+    secrets?: SealedSecrets;
     /** Address handed to eth0. */
     ipv4?: string;
     gateway?: string;

package/dist/{contracts-BHo4LdY2.d.cts → contracts-BFG82pSs.d.cts}

@@ -16,7 +16,7 @@ interface ChildHandle {
     exitCode: number | undefined;
     on(event: "stdout" | "stderr" | "exit" | "rawmode" | "fd", listener: (...args: any[]) => void): unknown;
     exec(): void;
-    sendStdin(data: string): void;
+    sendStdin(data: string | Uint8Array): void;
     /**
      * Close the child's input.
      *
@@ -95,6 +95,36 @@ declare function createChildProcessModule(spawnChild: SpawnChild, defaultCwd: ()
     ipc?: IpcTransport;
 }): Record<string, unknown>;
 
+/**
+ * Sealed secrets: credentials a guest can use but cannot read.
+ *
+ * A program inside the container names a secret — `{{secret:GITHUB_TOKEN}}` in
+ * a header — and the egress layer puts the value in as the request leaves, and
+ * only for the hosts that secret is bound to. The value is never in the
+ * filesystem, the environment or a process's arguments, so there is nothing
+ * for a prompt-injected `cat`, `env` or `curl evil.example` to send anywhere.
+ *
+ * Two things make that hold rather than merely sound good:
+ *
+ *   * A placeholder for a host the secret is not bound to is a refusal, not a
+ *     pass-through. Sending the literal `{{secret:…}}` onward would tell the
+ *     other side which secrets exist; sending the value would be the leak.
+ *   * What comes back is scanned. A server that echoes the request — plenty of
+ *     debugging endpoints do — would otherwise hand the value to the guest in
+ *     the response body.
+ *
+ * What this does not claim: the value lives in the memory of the runtime that
+ * performs the request. It is out of reach of every guest API, not of a
+ * debugger attached to the host.
+ */
+interface SealedSecret {
+    /** The credential itself. */
+    value: string;
+    /** Hosts it may be sent to; subdomains are included, as in `allowedHosts`. */
+    hosts: string[];
+}
+type SealedSecrets = Record<string, SealedSecret>;
+
 /**
  * The outbound network policy, as plain functions every client consults.
  *
@@ -109,6 +139,7 @@ declare function createChildProcessModule(spawnChild: SpawnChild, defaultCwd: ()
  * container, so those requests are routed to its own servers and never handed
  * to the host's network stack, whatever the policy allows.
  */
+
 interface OutboundPolicy {
     /** Whether requests may leave the container at all. */
     allowOutbound: boolean;
@@ -123,6 +154,13 @@ interface OutboundPolicy {
      * setting whose meaning depended on which language the guest was written in.
      */
     proxy?: string;
+    /**
+     * Credentials the egress layer adds to requests on the guest's behalf.
+     *
+     * A guest writes `{{secret:NAME}}` in a header; the value is substituted
+     * here, for the hosts it is bound to, and removed from whatever comes back.
+     */
+    secrets?: SealedSecrets;
 }
 
 /**
@@ -660,4 +698,4 @@ interface RuntimePod {
     teardown(): void;
 }
 
-export { type Cred as C, type DirEntry as D, type IpcTransport as I, type OutboundPolicy as O, type RuntimeVolume as R, type SpawnChild as S, Vfs as V, type WriteOptions as W, VirtualTcpNetwork as a, type RuntimeHttpResponse as b, type SyncSpawn as c, type VolumeStat as d, type VolumeStats as e, type RuntimePod as f, type RuntimePackageInstaller as g, type ChildSpawnConfig as h, type ChildHandle as i, type RuntimeProcess as j, type RuntimeSocketPeer as k, type RuntimeConnection as l, ROOT_CRED as m, type RuntimeProcessManager as n, type RuntimeProcessResult as o, Stats as p, type VirtualNode as q, type VirtualProvider as r, applyChmod as s, createChildProcessModule as t, formatMode as u, makeCred as v, octalMode as w, parseUmask as x };
+export { type Cred as C, type DirEntry as D, type IpcTransport as I, type OutboundPolicy as O, type RuntimeVolume as R, type SpawnChild as S, Vfs as V, type WriteOptions as W, VirtualTcpNetwork as a, type RuntimeHttpResponse as b, type SyncSpawn as c, type VolumeStat as d, type VolumeStats as e, type RuntimePod as f, type RuntimePackageInstaller as g, type ChildSpawnConfig as h, type ChildHandle as i, type RuntimeProcess as j, type RuntimeSocketPeer as k, type RuntimeConnection as l, ROOT_CRED as m, type RuntimeProcessManager as n, type RuntimeProcessResult as o, type SealedSecret as p, type SealedSecrets as q, Stats as r, type VirtualNode as s, type VirtualProvider as t, applyChmod as u, createChildProcessModule as v, formatMode as w, makeCred as x, octalMode as y, parseUmask as z };

package/dist/{contracts-BHo4LdY2.d.ts → contracts-BFG82pSs.d.ts}

@@ -16,7 +16,7 @@ interface ChildHandle {
     exitCode: number | undefined;
     on(event: "stdout" | "stderr" | "exit" | "rawmode" | "fd", listener: (...args: any[]) => void): unknown;
     exec(): void;
-    sendStdin(data: string): void;
+    sendStdin(data: string | Uint8Array): void;
     /**
      * Close the child's input.
      *
@@ -95,6 +95,36 @@ declare function createChildProcessModule(spawnChild: SpawnChild, defaultCwd: ()
     ipc?: IpcTransport;
 }): Record<string, unknown>;
 
+/**
+ * Sealed secrets: credentials a guest can use but cannot read.
+ *
+ * A program inside the container names a secret — `{{secret:GITHUB_TOKEN}}` in
+ * a header — and the egress layer puts the value in as the request leaves, and
+ * only for the hosts that secret is bound to. The value is never in the
+ * filesystem, the environment or a process's arguments, so there is nothing
+ * for a prompt-injected `cat`, `env` or `curl evil.example` to send anywhere.
+ *
+ * Two things make that hold rather than merely sound good:
+ *
+ *   * A placeholder for a host the secret is not bound to is a refusal, not a
+ *     pass-through. Sending the literal `{{secret:…}}` onward would tell the
+ *     other side which secrets exist; sending the value would be the leak.
+ *   * What comes back is scanned. A server that echoes the request — plenty of
+ *     debugging endpoints do — would otherwise hand the value to the guest in
+ *     the response body.
+ *
+ * What this does not claim: the value lives in the memory of the runtime that
+ * performs the request. It is out of reach of every guest API, not of a
+ * debugger attached to the host.
+ */
+interface SealedSecret {
+    /** The credential itself. */
+    value: string;
+    /** Hosts it may be sent to; subdomains are included, as in `allowedHosts`. */
+    hosts: string[];
+}
+type SealedSecrets = Record<string, SealedSecret>;
+
 /**
  * The outbound network policy, as plain functions every client consults.
  *
@@ -109,6 +139,7 @@ declare function createChildProcessModule(spawnChild: SpawnChild, defaultCwd: ()
  * container, so those requests are routed to its own servers and never handed
  * to the host's network stack, whatever the policy allows.
  */
+
 interface OutboundPolicy {
     /** Whether requests may leave the container at all. */
     allowOutbound: boolean;
@@ -123,6 +154,13 @@ interface OutboundPolicy {
      * setting whose meaning depended on which language the guest was written in.
      */
     proxy?: string;
+    /**
+     * Credentials the egress layer adds to requests on the guest's behalf.
+     *
+     * A guest writes `{{secret:NAME}}` in a header; the value is substituted
+     * here, for the hosts it is bound to, and removed from whatever comes back.
+     */
+    secrets?: SealedSecrets;
 }
 
 /**
@@ -660,4 +698,4 @@ interface RuntimePod {
     teardown(): void;
 }
 
-export { type Cred as C, type DirEntry as D, type IpcTransport as I, type OutboundPolicy as O, type RuntimeVolume as R, type SpawnChild as S, Vfs as V, type WriteOptions as W, VirtualTcpNetwork as a, type RuntimeHttpResponse as b, type SyncSpawn as c, type VolumeStat as d, type VolumeStats as e, type RuntimePod as f, type RuntimePackageInstaller as g, type ChildSpawnConfig as h, type ChildHandle as i, type RuntimeProcess as j, type RuntimeSocketPeer as k, type RuntimeConnection as l, ROOT_CRED as m, type RuntimeProcessManager as n, type RuntimeProcessResult as o, Stats as p, type VirtualNode as q, type VirtualProvider as r, applyChmod as s, createChildProcessModule as t, formatMode as u, makeCred as v, octalMode as w, parseUmask as x };
+export { type Cred as C, type DirEntry as D, type IpcTransport as I, type OutboundPolicy as O, type RuntimeVolume as R, type SpawnChild as S, Vfs as V, type WriteOptions as W, VirtualTcpNetwork as a, type RuntimeHttpResponse as b, type SyncSpawn as c, type VolumeStat as d, type VolumeStats as e, type RuntimePod as f, type RuntimePackageInstaller as g, type ChildSpawnConfig as h, type ChildHandle as i, type RuntimeProcess as j, type RuntimeSocketPeer as k, type RuntimeConnection as l, ROOT_CRED as m, type RuntimeProcessManager as n, type RuntimeProcessResult as o, type SealedSecret as p, type SealedSecrets as q, Stats as r, type VirtualNode as s, type VirtualProvider as t, applyChmod as u, createChildProcessModule as v, formatMode as w, makeCred as x, octalMode as y, parseUmask as z };