eve 0.81.1 → 0.83.0

package/docs/skills.mdx

@@ -9,7 +9,7 @@ A skill is a model-loadable procedure that follows the `SKILL.md` convention. It
 
 eve scans the files under `agent/skills/` and lists each one's name and description in the system prompt. When a request matches a skill's description (or you name the skill outright), the model loads it with `eve__skill({ name })`, and the skill's markdown becomes the call's result in the active turn. An agent with skills always has the [`eve__skill` tool](./concepts/built-in-tools#eve__search-eve__tool-and-eve__skill). A load reports a `load-skill` action named for the skill, and `t.loadedSkill` asserts it in [evals](./evals/assertions).
 
-Listing skills and loading their instructions do not require a sandbox: loading returns static instructions from the compiled agent and dynamic instructions from session state. Only access to supporting package files requires a sandbox. Builds may also prewarm sandbox templates that contain static package files. Supporting files are available under `$HOME/.agents/skills/<skill>/`, with `/workspace/skills/<skill>/` as the fallback when `$HOME` is unavailable. Sibling references inside `SKILL.md`, such as `references/checklist.md`, are relative to the directory containing that specific `SKILL.md`.
+Listing skills and loading their instructions do not require a sandbox: loading returns static instructions from the compiled agent and dynamic instructions from session state. Only access to supporting package files requires a sandbox. Builds may also prewarm sandbox templates that contain static package files. Supporting files are available under `$HOME/.agents/skills/<skill>/`, with `skills/<skill>/` under the workspace root as the fallback when `$HOME` is unavailable. Sibling references inside `SKILL.md`, such as `references/checklist.md`, are relative to the directory containing that specific `SKILL.md`.
 
 The description is a routing hint, not a label. Write it as the task that should trigger activation:
 

package/docs/subagents/index.mdx

@@ -34,6 +34,8 @@ The copy uses the root's instructions, connections, auth, and sandbox. It receiv
 
 The parent transfers data to the child through the `message` input it gives the subagent. Do not include sensitive data in a subagent request unless that child and its inherited tools, connections, sandbox, and telemetry path are appropriate for that data.
 
+An authored workflow can open the same root-copy target through `ctx.agent("agent")`. To keep the copied configuration but use another model for that child session, pass a [model override to `ctx.agent`](./tools/workflows#delegate-work-ctxagent). The default model-facing tool does not accept a model choice; an authored [`agentWithModel` tool](./concepts/built-in-tools#agent) can expose that choice in its input.
+
 To prevent the root session from delegating to a fresh copy of itself, set `tool: false` on the root agent:
 
 ```ts title="agent/agent.ts"
@@ -210,7 +212,7 @@ The root built-in `agent` tool is the exception. Its children reuse the root's s
 
 ## What the parent sees
 
-eve lowers every tool-enabled subagent visible to the current agent (the root built-in copy, declared, or [remote](./guides/remote-agents)) into a model-visible tool with the same `{ message, taskId? }` shape. The parent packs `message` with everything the child needs, since the child never sees the parent's history. To require structured output from a child, open a session with it from an authored workflow tool with [`ctx.agent(name)`](./tools/workflows#delegate-work-ctxagent) and pass `outputSchema` to `send()`; the schema applies to that turn, and the session accepts follow-up messages until the workflow run finishes.
+By default, eve lowers every tool-enabled subagent visible to the current agent (the root built-in copy, declared, or [remote](./guides/remote-agents)) into a model-visible tool with the same `{ message, taskId? }` shape. The opt-in [`agentWithModel` root-copy tool](./concepts/built-in-tools#agent) instead uses `{ message, model, taskId? }`. The parent packs `message` with everything the child needs, since the child never sees the parent's history. To require structured output from a child, open a session with it from an authored workflow tool with [`ctx.agent(name)`](./tools/workflows#delegate-work-ctxagent) and pass `outputSchema` to `send()`; the schema applies to that turn, and the session accepts follow-up messages until the workflow run finishes.
 
 Declared subagents can call nested subagents defined under their own directories. eve does not apply a separate depth limit; nesting ends where the authored directory tree ends. The built-in `agent` follows the stricter root-only rule above, so `limits.maxSubagentDepth` no longer exists.
 

package/docs/tools/overview.mdx

@@ -174,7 +174,8 @@ export default defineTool({
 });
 ```
 
-eve publishes every earlier yield as an `action.partial` stream event. The
+eve publishes earlier yields as `action.partial` stream events. When the durable
+writer is busy, eve may keep only the newest adjacent snapshot for a call. The
 snapshot is visible to channels, hooks, and clients but never enters model
 history or `toModelOutput`; only the final yield does. Treat snapshots as
 last-write-wins by tool call id, not append-only progress. The durable runtime
@@ -338,6 +339,25 @@ eve writes each returned file to the session sandbox and keeps only a reference
 
 When compaction drops older tool results, each file becomes a text reference such as `Attached file /workspace/.eve/attachments/<hash>/chart.png (image/png)`. The built-in `read_file` tool shows PNG, JPEG, GIF, and WebP images up to 3 MiB and PDFs up to 20 MiB to the model as files, so the agent can open a compacted image or PDF again.
 
+#### Send a file by URL
+
+For large files that already live in object storage, such as PDFs behind a presigned S3 link, return the URL instead of the bytes with `toolOutputPart.fileUrl`:
+
+```ts
+toModelOutput(output) {
+  return toolOutput.content([
+    toolOutputPart.text(`Contract ${output.id}:`),
+    toolOutputPart.fileUrl(output.signedUrl, { mediaType: "application/pdf" }),
+  ]);
+},
+```
+
+eve keeps only the URL in session history and does not write the file to the sandbox. The model provider fetches the URL itself when it supports that for the file's type; otherwise the AI SDK downloads the file before the call. Only `https:` URLs are accepted.
+
+Every later model call sends the same URL again, so it must stay readable for the rest of the session. A presigned URL that expires mid-session makes later model calls fail. The provider still counts the file's input tokens on each call, the same as an inline file.
+
+Unlike a staged file, a URL part has no sandbox path to fall back on. When compaction drops the tool result, the file becomes `Attached file <filename> (<mediaType>)` and the URL is gone. If the agent may need the file again later, also return a text part with an id or path the tool can fetch it by.
+
 Do not return secrets, credentials, unnecessary personal data, or unbounded sensitive content from tools. Filter, minimize, and redact tool outputs before returning them.
 
 ## What to read next

package/docs/tools/tasks-upgrade.md

@@ -158,15 +158,18 @@ reports each wait with the new `turn.waiting` event, which carries the open turn
   subagent's question, emitted `turn.completed` and `session.waiting` in the middle of the turn.
   It now emits `input.requested` or `authorization.required`, then `turn.waiting`, and the turn
   resumes under the same `turnId` after the answer. The session you answer on emits
-  `input.resolved` for every question it routes an answer to. A tool approval the turn itself
-  requests still ends the turn with `turn.completed` and `session.waiting`.
+  `input.resolved` for every question it routes an answer to. A sign-in or tool approval the
+  turn itself requests holds the turn the same way, with `turn.waiting` on `"input"`.
 - **`turn.completed` comes only when the turn really ends,** and `session.waiting` always means
   the turn has ended.
 
 The TypeScript client's `send(...).result()` reads past `turn.waiting` and returns the final reply
-of a held turn, not the text written before the wait. It stops at `turn.waiting` only while a
-question is pending, and returns `status: "waiting"` with that question; `respond()` then reads the
-same turn to its end. A custom client that ends a response at `turn.completed` or
+of a held turn, not the text written before the wait. At `turn.waiting`, an unanswered input
+request (a question, approval, or `session-limit` prompt) makes `result()` return
+`status: "waiting"`; use `respond()` to answer it and continue reading the same turn.
+A sign-in keeps the response attached while its authorization callback is pending. Render the
+sign-in prompt from the live `authorization.required` event rather than waiting for `result()`.
+A custom client that ends a response at `turn.completed` or
 `session.waiting` mid-turn, or that shows the first completed message as the reply, should follow
 the same rule. See [Aggregate a turn](/docs/guides/client/streaming#aggregate-a-turn).
 
@@ -197,5 +200,7 @@ Two things differ from a remote agent on the caller's own release:
 
 Each protocol-1 create logs `serving a remote agent protocol 1 caller` with the caller's origin.
 
-Upgrade a caller after every remote agent it calls. A caller on this release fails a call at start,
-with an error that names both versions, when the remote agent's deployment speaks protocol 1.
+Upgrade a caller after every remote agent it calls. A caller on this release accepts a protocol-1
+remote agent's results and failures, but that remote agent's approvals and sign-in requests don't
+reach the caller. Any other protocol mismatch fails the call at start, with an error that names
+both versions.

package/docs/tools/tasks.md

@@ -232,9 +232,12 @@ continues once the person answers or signs in.
 
 In every session, `turn.completed` comes only when the turn really ends. The TypeScript client's
 `send(...).result()` and the MCP channel's `agent_get` read past `turn.waiting` and report the
-final reply rather than the text written before the wait. `result()` stops at `turn.waiting` only
-while a question is pending or the turn waits on a sign-in or approval, and returns
-`status: "waiting"`; `respond()` then reads the same turn to its end. See [Aggregate a turn](/docs/guides/client/streaming#aggregate-a-turn).
+final reply rather than the text written before the wait. At `turn.waiting`, an unanswered input
+request (a question, approval, or `session-limit` prompt) makes `result()` return
+`status: "waiting"`; use `respond()` to answer it and continue reading the same turn.
+A sign-in keeps the response attached while its authorization callback is pending. Render the
+sign-in prompt from the live `authorization.required` event rather than waiting for `result()`.
+See [Aggregate a turn](/docs/guides/client/streaming#aggregate-a-turn).
 Channels such as [Slack](/docs/channels/slack) post a root session's text before the wait as an
 ordinary reply, then post the reply after the results as another message. Slack also shows each
 turn's tasks in a live [task card](/docs/channels/slack#task-card).
@@ -305,9 +308,10 @@ task's start and end instead. See
   and enforce per-person access inside the tool.
 - **Working tasks.** A session runs at most 32 working tasks at once. An idle resumable task doesn't
   count, and a call that makes it work again does.
-- **No time limits.** Tasks have no timeout of their own. The session lifetime,
-  `limits.sessionTimeoutMs` (30 days by default), bounds all work in a session. A body that needs a
-  deadline races `sleep` against its work.
+- **No time limits.** Tasks have no timeout of their own, and the session timeout does not bound
+  them. A turn held open while its tasks work keeps the session open, and
+  `limits.sessionTimeoutMs` (30 idle days by default) counts from when that turn settles. A body
+  that needs a deadline races `sleep` against its work.
 
 ## Upgrade from background tasks
 

package/docs/tools/workflows.mdx

@@ -90,9 +90,9 @@ or days later, the run resumes, deploys, and returns. The model sees one tool re
   `agent`, `agents`, `ask`, and `reply`; each call it receives carries its own `callId` and
   `abortSignal`.
   A `"use step"` helper that receives `ctx` directly gets a restricted `WorkflowStepToolContext` with
-  `session`, `callId`, `toolName`, `abortSignal`, `getToken`, and `requireAuth`. Read `ctx.agents`, call
+  `session`, `callId`, `toolName`, `abortSignal`, `getSandbox`, `getToken`, and `requireAuth`. Read `ctx.agents`, call
   `ctx.agent()`, and call `ctx.ask()` in the workflow body; pass only the serializable values the step needs.
-  `getSandbox` remains unavailable.
+  Call `getSandbox`, `getToken`, and `requireAuth` in a step: the workflow body throws when it calls them.
 - The tool's input must be a JSON object. Workflow bodies are for static tools under `agent/tools/`,
   not tools returned from `defineDynamic` resolvers.
 
@@ -146,9 +146,21 @@ continue a child from an earlier call. Agent authorization, questions, approvals
 behave as they do for sessions an authored workflow tool opens with `ctx.agent`.
 
 The sandbox resumes after every pending call in the current batch settles. `Promise.all` supports
-fan-out followed by fan-in, but `Promise.race` does not resume after only the first child settles.
-A failed child turn throws at the corresponding `ctx.agent` call, so generated code can catch it.
-The program must return a JSON-serializable value.
+fan-out followed by fan-in. The program must await every `ctx.agent` call before it returns. A call
+that is still pending at that point, such as one that is never awaited or one that loses a
+`Promise.race` or `Promise.any`, fails the workflow.
+
+A failed child turn, an invalid call, or a call over the `maxSubagents` budget throws a
+`WorkflowProgramAgentError` at that `ctx.agent` call, which the program can catch; the message
+says which.
+
+The sandbox converts the program's return value and each `ctx.agent` input with `JSON.stringify`,
+so a `Date` becomes a string and functions and `undefined` members drop. A return value that
+converts to nothing, such as `undefined`, becomes `null`. Each converted value may be up to 1 MiB of
+JSON, each child reply up to 4 MiB of JSON, and the program source up to 256 KiB.
+
+Each start or resume may spend up to 30 seconds running JavaScript and up to 5 minutes in total.
+Time spent waiting for child agents does not count toward either limit.
 
 ### Migrate from `experimental_workflow`
 
@@ -438,6 +450,62 @@ itself contains no credentials.
 Cancelling an authorization wait withdraws its callback. Cancellation uses the existing turn
 cancellation path rather than a separate authorization completion event.
 
+## Use the session sandbox in a step
+
+Pass `ctx` directly to a step helper and call `ctx.getSandbox()` there. The step opens the
+[sandbox](/docs/sandbox) of the session that called the tool, the same sandbox that session's
+turns use. When the session shares its parent's sandbox, as a copy started by the built-in `agent`
+tool does, the step opens that shared sandbox. The step sees files the session wrote, and the
+session's later tool calls see files the step writes:
+
+```ts title="agent/tools/analyze.ts"
+import { defineWorkflowTool, type WorkflowStepToolContext } from "eve/tools";
+import { z } from "zod";
+
+export default defineWorkflowTool({
+  description: "Prepare the input file for an analysis run.",
+  inputSchema: z.object({ value: z.string() }),
+  async task(input, ctx) {
+    "use workflow";
+    await prepareInput(ctx, input);
+    return { path: "/workspace/input.json" };
+  },
+});
+
+async function prepareInput(ctx: WorkflowStepToolContext, input: { value: string }) {
+  "use step";
+  const sandbox = await ctx.getSandbox();
+  await sandbox.writeTextFile({ path: "/workspace/input.json", content: JSON.stringify(input) });
+}
+```
+
+- The workflow body cannot open the sandbox, because it replays. `ctx.getSandbox()` in the body
+  throws and tells you to pass `ctx` to a step helper.
+- The step opens the sandbox directly, with any sandbox provider. If the session recorded its
+  sandbox before it called the tool, the step resumes it. Otherwise, or if that sandbox is gone by
+  the time the step runs, the step opens it the way the session's first turn would: it runs your
+  `defineSandbox()` definition, and the provider finds or creates the sandbox by the session's id. The session's later turns open the same sandbox. Your
+  definition can run once for each caller that opens the sandbox before the session records it,
+  so make its initialization safe to repeat.
+- The step does not own the sandbox. When the step ends, even by throwing, eve lets go of the
+  step's handle and leaves the sandbox running for the session. eve never stops or deletes the
+  sandbox for a step, and `sandbox.stop()` and `sandbox.delete()` in a step fail without a retry,
+  because the session's turns may be using the sandbox.
+- The session removes the sandbox when the session ends, even when only a step opened it. A step
+  that is still running when the session ends can open the sandbox again after that cleanup, and
+  nothing removes the new one.
+- When the eve server shuts down, it stops the sandboxes its sessions opened, but not one that
+  only a step opened. With Docker, that container keeps running until the session ends or you
+  stop it.
+- A step can use the sandbox while the session's turns use it too, as subagents that share a
+  sandbox do. Give each one its own files to write.
+- Steps run at least once and retry after a failure, so make sandbox writes safe to repeat. Write
+  whole files instead of appending to them, or check for earlier output first.
+- When the session shares its parent's sandbox, the step opens it by the parent's session id with
+  the parent's sandbox definition, and the parent removes it when the parent ends.
+- A step runs wherever the workflow runs. A sandbox that lives on one machine, such as just-bash
+  on the local disk, is reachable from a step only on that machine, as in local development.
+
 ## Ask a human: `ctx.ask`
 
 ```ts
@@ -502,9 +570,9 @@ and can only show the model's input. Both compose: `approval` before the run, `c
 
 ## Delegate work: `ctx.agent`
 
-`ctx.agent(name)` returns a session with an agent, shaped like the TypeScript client's session. The
-session opens on its first `send`, and each `response.result()` resolves when that message's turn
-ends:
+`ctx.agent(name, options?)` returns a session with an agent, shaped like the TypeScript client's
+session. The session opens on its first `send`, and each `response.result()` resolves when that
+message's turn ends:
 
 ```ts
 import { z } from "zod";
@@ -517,6 +585,37 @@ const response = await reviewer.send("Review the deployment plan for security ri
 const { data, message, status } = await response.result();
 ```
 
+Set `model` when the workflow should run a local child with a different AI Gateway model. The
+selection belongs to the returned session, so every message sent through that handle uses it:
+
+```ts
+const reviewer = ctx.agent("agent", {
+  model: "anthropic/claude-opus-5.5",
+});
+
+const response = await reviewer.send("Review the migration plan.", {
+  signal: ctx.abortSignal,
+});
+```
+
+The override changes only the model. The child keeps the target agent's instructions, tools, skills,
+connections, sandbox behavior, limits, reasoning, and explicit compaction model. Pass a selection
+object to override model-specific settings too:
+
+```ts
+const reviewer = ctx.agent("agent", {
+  model: {
+    model: "anthropic/claude-opus-5.5",
+    modelContextWindowTokens: 200_000,
+    reasoning: "high",
+  },
+});
+```
+
+The selection must contain an AI Gateway model id. A live AI SDK `LanguageModel` cannot cross the
+durable workflow boundary. A remote agent rejects the option because its deployment owns its model
+configuration.
+
 The name is an available agent target. On the root agent, `"agent"` starts a copy of the root agent.
 A declared subagent uses its path-derived name and remains callable when hidden with `tool: false`
 or `disableTool()`. Delegated root copies and declared subagent contexts do not expose the built-in
@@ -544,8 +643,8 @@ client's `MessageResult` fields, plus `error` when the turn failed:
 | `status`  | `"waiting"` when the session waits for its next message, `"completed"` when the session ended with the turn, or `"failed"` when the turn failed. A cancelled turn is `"waiting"` with neither `data` nor `message`. |
 | `error`   | `{ message }` with the reason the turn failed, present only when `status` is `"failed"`.                                                                                                                            |
 
-Every `ctx.agent(name)` call returns a new session that only the workflow run can address. The model
-does not see it; it sees what the tool returns. A local child runs as the caller's principal with the
+Every `ctx.agent(name, options?)` call returns a new session that only the workflow run can address.
+The model does not see it; it sees what the tool returns. A local child runs as the caller's principal with the
 caller's capabilities. A remote child does not inherit the caller's session principal by default;
 the receiving deployment determines its identity from the outbound request. To forward the caller's
 identity, set `forwardPrincipal: true` on the remote agent and configure the receiver's

package/docs/tutorial/connect-a-warehouse.mdx

@@ -72,7 +72,7 @@ If the user has not authorized the connector, the turn parks and the channel sho
 
 ## The token never reaches the model
 
-Right before each request to the MCP server, eve resolves the bearer and sends it as `Authorization: Bearer <token>`. The model sees tool names, descriptions, and results. The credential stays in the app runtime.
+Right before each request to the MCP server, eve resolves the user's bearer and, once the user has authorized, sends it as `Authorization: Bearer <token>`. The model sees tool names, descriptions, and results. The credential stays in the app runtime.
 
 Gate the connection behind approval (`approval: once()`) or narrow which tools the model sees (`tools.allow`) when needed. See [MCP connections](../connections/mcp).
 

package/docs/tutorial/run-analysis.mdx

@@ -29,9 +29,9 @@ Top-level workspace entries get advertised to the model automatically, so it kno
 
 ## Install the chart dependencies
 
-Python needs a sandbox that runs real binaries. For local development, start a Docker-compatible daemon and run `docker info` to verify it is reachable before restarting `npm run dev`. eve also supports [microsandbox](../sandbox#microsandbox) on compatible hosts. The `just-bash` fallback cannot run Python or install packages; installing Python on your laptop does not add it to the sandbox. You can [continue to the next chapter](./remember-definitions) if you do not want to set up a local container or VM yet.
+Python needs a sandbox that runs real binaries. For local development, start a Docker-compatible daemon and run `docker info` to verify it is reachable before restarting `npm run dev`. The `just-bash` fallback cannot run Python or install packages; installing Python on your laptop does not add it to the sandbox. You can [continue to the next chapter](./remember-definitions) if you do not want to set up a local container yet.
 
-The default eve images for Docker, microsandbox, and Vercel Sandbox include Python, but not matplotlib. Add this definition alongside `workspace/` to install matplotlib in a virtual environment. It uses the same environment for installation and chart execution, without changing the system Python:
+The default eve images for Docker and Vercel Sandbox include Python, but not matplotlib. Add this definition alongside `workspace/` to install matplotlib in a virtual environment. It uses the same environment for installation and chart execution, without changing the system Python:
 
 ```ts title="agent/sandbox/sandbox.ts"
 import { DefaultSandbox, defineSandbox } from "eve/sandbox";
@@ -217,7 +217,7 @@ This example caps charts at 1 MiB because tool outputs are persisted with sessio
 
 ## Secrets stay out of the sandbox
 
-The sandbox has no `process.env` and no access to your app's secrets. The `run_sql` tool and sample database run in your app. You pass only the query results to the chart tool; the sandbox does not need database credentials.
+The sandbox doesn't inherit your app's `process.env`. Secrets you pass explicitly through an environment or per-call `env` option are available inside the sandbox. The `run_sql` tool and sample database run in your app. You pass only the query results to the chart tool; the sandbox does not need database credentials.
 
 The local backend runs the sandbox on your laptop during `eve dev`; on Vercel it runs on Vercel Sandbox. Lifecycle, backends, and network policy are in [Sandbox](../sandbox).
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "eve",
-  "version": "0.81.1",
+  "version": "0.83.0",
   "private": false,
   "description": "Filesystem-first framework for durable backend AI agents that run anywhere.",
   "keywords": [
@@ -262,11 +262,6 @@
       "import": "./dist/src/public/sandbox/just-bash.js",
       "default": "./dist/src/public/sandbox/just-bash.js"
     },
-    "./sandbox/microsandbox": {
-      "types": "./dist/src/public/sandbox/microsandbox.d.ts",
-      "import": "./dist/src/public/sandbox/microsandbox.js",
-      "default": "./dist/src/public/sandbox/microsandbox.js"
-    },
     "./sandbox/vercel": {
       "types": "./dist/src/public/sandbox/vercel.d.ts",
       "import": "./dist/src/public/sandbox/vercel.js",
@@ -511,6 +506,11 @@
       "import": "./dist/src/public/channels/discord/index.js",
       "default": "./dist/src/public/channels/discord/index.js"
     },
+    "./channels/discord/gateway": {
+      "types": "./dist/src/public/channels/discord/gateway/index.d.ts",
+      "import": "./dist/src/public/channels/discord/gateway/index.js",
+      "default": "./dist/src/public/channels/discord/gateway/index.js"
+    },
     "./channels/twilio": {
       "types": "./dist/src/public/channels/twilio/index.d.ts",
       "import": "./dist/src/public/channels/twilio/index.js",
@@ -561,7 +561,6 @@
   "devDependencies": {
     "@agentclientprotocol/sdk": "1.3.0",
     "@ai-sdk/anthropic": "^4.0.78",
-    "@ai-sdk/code-mode": "^1.0.94",
     "@ai-sdk/google": "^4.0.93",
     "@ai-sdk/mcp": "^2.0.73",
     "@ai-sdk/openai": "^4.0.91",
@@ -600,12 +599,12 @@
     "@vercel/sandbox": "3.3.0",
     "@vercel/schedules": "0.0.0-alpha.11",
     "@vercel/sdk": "1.28.8",
-    "@workflow/core": "5.2.0",
-    "@workflow/errors": "5.0.3",
+    "@workflow/core": "5.2.3",
+    "@workflow/errors": "5.0.5",
     "@workflow/serde": "5.0.0",
-    "@workflow/world": "5.0.3",
-    "@workflow/world-local": "5.1.0",
-    "@workflow/world-vercel": "5.2.0",
+    "@workflow/world": "5.0.5",
+    "@workflow/world-local": "5.1.2",
+    "@workflow/world-vercel": "5.2.3",
     "ai": "^7.0.137",
     "chat": "4.42.0",
     "chokidar": "5.0.0",
@@ -620,13 +619,12 @@
     "just-bash": "3.1.0",
     "just-secrets": "0.0.2",
     "marked": "17.0.6",
-    "microsandbox": "0.5.5",
-    "next": "16.3.4",
+    "next": "16.3.8",
     "picocolors": "1.1.1",
     "playwright-core": "1.63.0",
     "react": "19.2.6",
     "react-test-renderer": "19.2.6",
-    "run": "2.1.2",
+    "run": "2.1.8",
     "semver": "7.8.4",
     "svelte": "^5.0.0",
     "turndown": "7.2.4",
@@ -642,8 +640,7 @@
     "braintrust": "^3.0.0",
     "chat": "^4.42.0",
     "dd-trace": "^6.13.0",
-    "just-bash": "^3.1.0",
-    "microsandbox": "^0.5.0"
+    "just-bash": "^3.1.0"
   },
   "peerDependenciesMeta": {
     "@opentelemetry/api": {
@@ -660,9 +657,6 @@
     },
     "just-bash": {
       "optional": true
-    },
-    "microsandbox": {
-      "optional": true
     }
   },
   "engines": {

package/dist/src/compiled/@ai-sdk/code-mode/_run.d.ts

@@ -1 +0,0 @@
-export declare function setMaxWorkers(maxWorkers?: number): void;