eve 0.70.1 → 0.70.3

package/docs/channels/slack.mdx

@@ -457,20 +457,26 @@ The bases say where a call may go. `apiBaseUrl` is the base Slack Web API method
 
 eve shows an agent's progress in two places. Short work, such as thinking or a tool call, appears in the thread status and never posts a message. [Tasks](/docs/tools/tasks), which keep working while the conversation continues, appear in a task card: one message per turn that eve updates in place. Replies post as ordinary messages, so the thread holds the conversation, the task card, and nothing else.
 
-| Moment                             | Thread status                                                                   |
-| ---------------------------------- | ------------------------------------------------------------------------------- |
-| A mention or DM arrives            | `Thinking...`, right away, while the message hook is still deciding             |
-| The message hook drops the message | Cleared                                                                         |
-| The turn starts                    | `Working...`                                                                    |
-| The model reasons                  | The first line of its reasoning                                                 |
-| The model calls tools              | Its narration before the calls, or an action label such as `Search useEveAgent` |
-| The turn waits on its tasks        | `Waiting on researcher...`, or `Waiting on 3 tasks...`                          |
-| The model starts its next step     | `Reviewing results...` after a task finishes, otherwise `Thinking...`           |
-| A reply posts                      | Cleared by Slack                                                                |
-
-Slack clears a thread status after two minutes without a message, so during a long wait the task card is what shows the work is still going.
-
-Action labels follow the same rule as the task card titles described below, plus `+N more` when the model requests several actions at once. They leave out the model's own `task_wait` and `task_cancel` calls. Reasoning snippets build progressively: extensions of at least four characters appear immediately, while smaller streamed deltas use a five-second refresh interval to avoid one Slack request per token.
+| Moment                                            | Thread status                                                                                                                      |
+| ------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------- |
+| A mention or DM arrives                           | `Thinking...`, right away, while the message hook is still deciding                                                                |
+| The message hook drops the message                | Cleared                                                                                                                            |
+| The turn starts                                   | `Thinking...`                                                                                                                      |
+| The model reasons                                 | Its latest reasoning heading, or its latest finished sentence                                                                      |
+| The model calls tools                             | Its narration before the calls, or the first action label, such as `Search useEveAgent`, plus `+N more` for the step's other calls |
+| A tool reports progress                           | The tool's `label.delta` text                                                                                                      |
+| A tool finishes                                   | The tool's `label.complete` text, when it defines one; otherwise the status stays                                                  |
+| The model starts its next step                    | `Reviewing researcher's results...` after a task finishes, otherwise the same status again                                         |
+| The model streams a long reply                    | `Writing a reply...`, once the text runs past 280 characters                                                                       |
+| The turn waits on its tasks                       | `Waiting on researcher...`, or `Waiting on 3 tasks...`                                                                             |
+| The turn waits on an approval, answer, or sign-in | Cleared until the turn resumes, then the status it had                                                                             |
+| A reply posts                                     | Cleared by Slack                                                                                                                   |
+
+A model step never resets the status to a generic line. The status keeps naming the latest work until something newer replaces it, so a user watching the thread sees `Checking recent deploys`, then `Found 4 failed deploys`, then `Reading build logs`, without `Thinking...` in between.
+
+Slack removes a thread status after two minutes without a message from the app, and clears it whenever the app posts in the thread. eve sets the current status again at each model step, after it posts a new task card, and as a tool reports progress. A tool that runs longer than two minutes without reporting progress loses its status. Report progress with [`label.delta`](/docs/tools#label-tool-activity), or run the work as a [task](/docs/tools/tasks), whose card shows it is still going.
+
+Action labels follow the same rule as the task card titles described below. They leave out the model's own `task_wait` and `task_cancel` calls. Reasoning shows one piece at a time: a heading when the model titles its reasoning, as reasoning summaries do, otherwise the latest finished sentence. Each piece of reasoning, and each progress label, stays up for at least three seconds, so the status changes at a readable pace instead of sending a Slack request per token. Every status is cut to 50 characters at a word boundary.
 
 Replies up to 12,000 characters render inline. Longer replies are uploaded unchanged as a Markdown snippet named `eve-response.md` with a short in-thread note, which requires the `files:write` bot scope.
 
@@ -792,7 +798,7 @@ Private file downloads resolve credentials from the session's app installation w
 
 Downloads cover Slack's own file hosts plus URLs under a configured [`api.fileBaseUrl`](#point-the-channel-at-a-different-slack-api-host), and travel on `api.fetch` when one is configured.
 
-Staged files live in the session sandbox under `/workspace/attachments`. Session history keeps a reference to that path, not a second copy of the Slack file. If the backend can no longer reattach the original sandbox, eve cannot restore the attachment bytes from history; later turns receive a missing-file result. Store files outside the sandbox when the agent must retain them independently of sandbox availability.
+Staged files live in the session sandbox under `/workspace/.eve/attachments`. Session history keeps a reference to that path, not a second copy of the Slack file. If the backend can no longer reattach the original sandbox, eve cannot restore the attachment bytes from history; later turns receive a missing-file result. Store files outside the sandbox when the agent must retain them independently of sandbox availability.
 
 ## What to read next
 

package/docs/channels/twilio.mdx

@@ -62,7 +62,7 @@ The default `message.completed` handler sends the reply as SMS through Twilio's
 
 ### Human-in-the-loop (HITL)
 
-SMS and voice have no native button or card affordance, so HITL prompts do not render as interactive controls. The agent's `input.requested` event reaches your `events["input.requested"]` handler if you declare one. Handle it by sending the prompt as text and mapping the caller's reply back to the input request yourself.
+SMS has no buttons or cards, so the default `input.requested` handler sends each question and tool approval as an SMS with its options numbered. A reply with an option's number or label answers the pending request, so `1` or `approve` runs an approval-gated tool and `2` or `cancel` stops it. If the question allows a custom answer, any other text is taken as that answer. Callers on a voice call get the question by SMS too. To render questions differently, declare your own `events["input.requested"]` handler.
 
 ### Proactive sessions
 

package/docs/code-extension.mdx

@@ -0,0 +1,119 @@
+---
+title: "Code Extension"
+description: "Mount eve's coding extension, eve-code, and see its latest benchmark results against other coding agent harnesses."
+---
+
+`eve/extensions/code` (eve-code) turns an eve agent into a coding agent. It ships inside the `eve` package, so you mount it without installing anything else. The extension contributes file-editing and search tools, an authenticated GitHub CLI tool, coding skills, a read-only worker subagent, and sandbox bootstrap helpers.
+
+## Benchmark results
+
+12 tasks × 3 attempts on `anthropic/claude-sonnet-5.5`. Snapshot updated 2026-10-03.
+
+| Harness | Resolved | 95% interval | Median latency | p90 latency | Measured |
+| --- | --- | --- | --- | --- | --- |
+| `pi` | 72% (26/36) | 50%–92% | 266.7s | 340.5s | 2026-09-30 |
+| `eve-code` | 67% (24/36) | 53%–81% | 235.4s | 389.7s | 2026-09-30 |
+| `opencode` | 50% (18/36) | 28%–72% | 611.7s | 1170.3s | 2026-09-30 |
+
+These results show baseline performance. Each harness uses its standard setup with high reasoning. The results do not show how a harness performs with other models, settings, or tasks.
+
+<details>
+<summary>How the benchmark works</summary>
+
+The benchmark uses eve-bench and the DeepSWE-lean dataset. DeepSWE-lean has 12 feature and bug-fix tasks from DeepSWE v1.1.
+
+- All harnesses use the same model and the same tasks.
+- Each harness does each task 3 times.
+- Each attempt runs in a new Vercel Sandbox.
+- Each attempt has a limit of 20 minutes.
+- The DeepSWE verifier examines the files that the agent leaves.
+- An attempt passes only when the verifier passes.
+- A crash or a timeout is a failure.
+
+The line on each correctness row shows the 95% interval. When the lines of two harnesses overlap, the benchmark does not show a difference between them.
+
+</details>
+
+<details>
+<summary>How the results update</summary>
+
+1. A maintainer runs the `eve-code` workflow on `main` with the `deepswe-lean` dataset.
+2. The workflow runs eve-code, opencode, and pi. It saves each complete result in the eve-bench result store.
+3. The workflow writes a summary of the result to `apps/docs/lib/evals/eve-code-benchmark.json`. Then it commits the file to `main`.
+4. The next docs deployment shows the new results.
+
+The workflow does not publish incomplete runs, single-task runs, or pull request runs. Results can be older than `main`, because a maintainer starts each run. Select a harness name to open the GitHub Actions run for that result.
+
+</details>
+
+## Mount the extension
+
+Create an extension file in your agent. The file name sets the mount name, which prefixes every contributed tool and subagent ID (for example, `code__grep`):
+
+```ts title="agent/extensions/code.ts"
+import code from "eve/extensions/code";
+
+export default code({});
+```
+
+`code({})` mounts the extension without GitHub or Vercel authentication. Add the options below when the agent needs them.
+
+## Configure the extension
+
+| Option                         | Required      | Effect                                                                                         |
+| ------------------------------ | ------------- | ---------------------------------------------------------------------------------------------- |
+| `github.connector`             | With `github` | Connector that mints a GitHub token                                                            |
+| `github.org`                   | With `github` | Organization whose repositories the `gh` tool can access                                       |
+| `github.broker`                | With `github` | `broker(sandbox, rules)` callback that installs, then removes, the GitHub credential rules     |
+| `vercel.connector`             | With `vercel` | Connector that requests an app-subject Vercel token                                            |
+| `vercel.delivery`              | No            | `"firewall"` (default) or `"command"`                                                          |
+| `broker`                       | No            | `broker(sandbox, rules)` callback that merges Vercel credential rules into your network policy |
+| `worker.model`                 | With `worker` | Model for the `worker` subagent. Defaults to `openai/gpt-5.6-terra-fast`                       |
+| `worker.reasoning`             | With `worker` | Reasoning level for the `worker` subagent. Defaults to `xhigh`                                 |
+| `worker.openaiReasoningEffort` | No            | Passed to OpenAI models as `reasoningEffort`                                                   |
+
+```ts title="agent/extensions/code.ts"
+import code from "eve/extensions/code";
+
+export default code({
+  vercel: { connector: "vercel/acme-bot" },
+  worker: { model: "openai/gpt-5.6-terra-fast", reasoning: "high" },
+});
+```
+
+### Credentials stay outside the sandbox
+
+With firewall delivery, Vercel tokens never enter sandbox processes. Firewall delivery without a top-level `broker` requires a sandbox provider that exposes `setNetworkPolicy()`, and fails otherwise. Set `vercel.delivery: "command"` for providers without a mutable network policy.
+
+The `gh` tool requests a token scoped to exactly one repository in `github.org` for each invocation. The sandbox process receives a placeholder `GH_TOKEN`, and the firewall exchanges it on matching GitHub requests. Your `github.broker` callback receives the header-transform rules for the command, then `null` to remove the lease. The callback must preserve your other network rules. GitHub authentication has no command-delivery option.
+
+To use a personal access token or another credential provider, omit the connector and call `authenticateGitHub` or `authenticateVercel` from `eve/extensions/code/sandbox` in your own sandbox lifecycle. These helpers authenticate commands you run yourself; they do not configure the `gh` tool.
+
+## Prepare the sandbox
+
+Install the CLI tooling in your sandbox environment's `prepare` callback:
+
+```ts title="agent/sandbox.ts"
+import { defineSandbox } from "eve/sandbox";
+import { VercelSandbox } from "eve/sandbox/vercel";
+import { installCodeTooling } from "eve/extensions/code/sandbox";
+
+export const environment = VercelSandbox.environment({
+  prepare: async (sandbox) => {
+    await installCodeTooling(sandbox, { vercel: true });
+  },
+});
+
+export default defineSandbox(() => environment.open());
+```
+
+Preparation installs `gh`, wrappers for `gh`, `vc`, and `gh-signed-commit`, and TypeScript diagnostics. For repositories that require verified signatures, stage your changes and commit with `gh-signed-commit`.
+
+eve derives the prepared environment generation from the sandbox file and environment options, not from imported helpers. Upgrading eve alone does not rebuild an existing prepared environment.
+
+## What to read next
+
+- [Extensions](/docs/extensions): mount, configure, and override extension packages
+- [Sandbox](/docs/sandbox): environments, preparation, and network policy
+- [Subagents](/docs/subagents): how declared subagents run and inherit configuration
+- [Skills](/docs/skills): how the model loads skills on demand

package/docs/concepts/built-in-tools.md

@@ -64,7 +64,7 @@ export default disableTool();
 
 ### `read_file`
 
-`read_file` reads text files from the sandbox with line-numbered output. It accepts absolute paths and paths beginning with `$HOME/`.
+`read_file` reads text files from the sandbox with line-numbered output, and shows PNG, JPEG, GIF, and WebP images up to 3 MiB to the model as images. It accepts absolute paths and paths beginning with `$HOME/`.
 
 ```sh
 eve add tool/read_file

package/docs/concepts/default-harness.md

@@ -36,6 +36,10 @@ if a turn is running, eve queues it until that turn settles. A successful manual
 compaction emits the same `compaction.requested` and `compaction.completed`
 events as automatic compaction, followed by `session.waiting`.
 
+After either kind of compaction, eve moves the idle session to a fresh workflow
+run on the same deployment, so a long session's run history does not keep
+growing. See [Execution model and durability](./execution-model-and-durability#compaction-handoff).
+
 To discard model-message history instead of summarizing it, call the corresponding
 `clear()` method on any of those handles. Clearing preserves the session identity,
 system prompt, configured tools and skills, durable state, limits, and sandbox.

package/docs/concepts/execution-model-and-durability.mdx

@@ -25,12 +25,18 @@ The Workflow SDK is not inherently tied to Vercel. In local development and in a
 
 When a Vercel production deployment changes, a new delivery to an idle session hands the session's settled state to the exact deployment that accepted the request. This applies whether the delivery arrives through the session ID or through any channel continuation address the session has claimed. The session keeps its original ID and event stream, while the next model turn uses that deployment's current system-role instructions, model, and tools. Static user-role instructions stay pinned in the durable conversation history and are not seeded again. A successful handoff restarts the session's original configured [`sessionTimeoutMs`](../agent-config#runtime-limits) duration; disabled timeouts stay disabled. Failed or skipped handoffs keep the existing deadline.
 
-Before taking ownership, the target deployment upgrades the checkpoint when an older eve release wrote it, then checks that no pending work remains. A deployment accepts checkpoints from eve 0.66.0 and later, so upgrading eve does not leave long-lived sessions, such as a Slack thread, on their old deployment. An older release cannot read a newer checkpoint: after a rollback, a session that already moved to the newer deployment stays there. Extension state saved before eve 0.69 moves to its mount when exactly one mount uses that extension package and the extension still defines that state. Otherwise eve cannot choose an owner, and the session stays on its current deployment. Idle subagent sessions that eve 0.66–0.68 kept for later reuse are stopped after the handoff. Authored session state remains opaque to this validation.
+Before taking ownership, the target deployment upgrades the checkpoint when an older eve release wrote it, then checks that no pending work remains. A deployment accepts checkpoints from eve 0.66.0 and later, so upgrading eve does not leave long-lived sessions, such as a Slack thread, on their old deployment. An older release cannot read a newer checkpoint: after a rollback, a session that already moved to the newer deployment stays there. Extension state saved before eve 0.69 moves to its mount when exactly one mount of that extension package defines that state. State that the target deployment no longer defines, such as a removed `defineState` key, is dropped, and the target deployment's runtime logs show a `dropping unknown context key during deserialization` warning. When two or more mounts of one extension package define that state, eve cannot choose an owner, and the session stays on its current deployment. Idle subagent sessions that eve 0.66–0.68 kept for later reuse are stopped after the handoff. Authored session state remains opaque to this validation.
 
 If the target deployment rejects the session, the previous owner keeps it and processes the triggering delivery. When the target deployment cannot read the checkpoint, its Vercel runtime logs show a `session handoff refused` warning with the checkpoint version and the reason. Owners on this release or later also write a `session handoff failed` warning to their own runtime logs, with the target deployment and the reason.
 
 eve does not move live work between deployments. A session with a running turn, pending human input or authorization, queued messages, or active tasks and subagents stays on its current deployment. After that work settles, a later delivery can move the idle session; the earlier deployment signal is not remembered.
 
+### Compaction handoff
+
+Every workflow run records each step it executes, so a session that ran on one run for weeks would carry its whole history in that run. To bound this, eve moves a session to a fresh run on its current deployment after [compaction](./default-harness#compaction) rewrites the conversation history. This applies to automatic compaction during a turn and to a client or channel compaction request.
+
+The move happens once the turn settles and nothing else is waiting: no queued messages, running tasks or subagents, or pending human input. The new run receives the compacted history and settled state, then waits for the next message. If a single message reaches an otherwise idle session before the move completes, eve moves the session with that message, and the message's turn runs on the new run. If work is still pending, eve tries again after a later turn settles. The session keeps its ID, event stream, continuation addresses, and deadline; compaction never extends [`sessionTimeoutMs`](../agent-config#runtime-limits). If the new run cannot take ownership, the current run keeps the session, writes a `session handoff failed` warning to its runtime logs, and tries again later.
+
 ### Upgrading sessions from the former execution model
 
 You can upgrade directly from a release that used a session driver and separate

package/docs/concepts/sessions-runs-and-streaming.md

@@ -12,8 +12,8 @@ controls, and streams. Every operation targets that exact session; none follows
 or creates a replacement implicitly.
 
 The session ID currently identifies the original Workflow run that owns the
-event stream. A deployment handoff changes the executing run, not the session
-ID or stream. Stream namespaces belong to a run; eve does not support
+event stream. A deployment or compaction handoff changes the executing run, not
+the session ID or stream. Stream namespaces belong to a run; eve does not support
 caller-assigned session IDs or globally addressed streams.
 
 Authored channels also have channel-local continuation tokens. A token addresses
@@ -24,7 +24,7 @@ by the eve HTTP session API. See [Custom channels](../channels/custom#channel-op
 Sessions last 30 days by default; configure `limits.sessionTimeoutMs` in
 `agent.ts`, or set it to `false` to disable the deadline. A successful deployment
 handoff or legacy-session import restarts the original configured duration.
-Ordinary messages and process restarts keep the existing deadline. At expiration, eve
+Ordinary messages, compaction handoffs, and process restarts keep the existing deadline. At expiration, eve
 lets an active turn settle, emits `session.completed`, and releases the
 session's continuation addresses so the next qualifying channel message starts fresh. Stored
 session data is not deleted. See [Agent config](../agent-config#runtime-limits).
@@ -123,7 +123,7 @@ Note: consider the privacy, confidentiality, and user-experience implications fo
 
 A delegated subagent publishes progress on its own child-session stream. When a subagent tool call or a workflow tool's `ctx.agent` opens a session, the parent emits `agent.started` with the call's `callId` and `turnId`, its `taskId` when the call runs as a task, the child's `sessionId`, and a `streamPath` that a client follows with `session.agent(started).stream()`. A subagent tool call is a [task](#task-events) whose `task.started` has `kind: "agent"`: its `task.started` and `task.settled` carry the call, and `task.settled.data.output` is the child's reply. A call that fails before the child session opens has no `agent.started`. A settled call does not end the child session; later calls with the same `taskId` reach it.
 
-A question or sign-in from inside a running call does not end the turn. This covers a workflow tool's `ctx.ask()`, including the built-in `ask_question` tool, and a delegated subagent's question or sign-in. The stream emits `input.requested` or `authorization.required`, then `turn.waiting` with `on: "input"` and the open turn's `turnId`. After the answer or sign-in, the turn resumes with the next `step.started` for the same `turnId`, and only `turn.completed`, `turn.failed`, or `turn.cancelled` ends it. When you answer a question that belongs to a workflow tool or a subagent, the session you answer on emits `input.resolved` for it as it routes the answer down. If the workflow tool run that relayed a question or approval ends before anyone answers, that session emits `input.resolved` with `outcome: "cancelled"` for it. This covers the run's own `ctx.ask()` questions and requests from sessions it opened with `ctx.agent`. A cancelled turn does the same for every question or approval the session relays. A sign-in or tool approval the turn raises itself holds it the same way, also with `on: "input"`. A message from the same person steers the turn and cancels the request: a sign-in reports `authorization.completed` with `outcome: "declined"`, and an approval reports `input.resolved` with `outcome: "ignored"`. Messages from other people wait until the turn ends. Cancelling the turn ends both: a held sign-in reports `authorization.completed` with `outcome: "declined"`, and a held approval reports `input.resolved` with `outcome: "cancelled"`.
+A question or sign-in from inside a running call does not end the turn. This covers a workflow tool's `ctx.ask()`, including the built-in `ask_question` tool, and a delegated subagent's question or sign-in. The stream emits `input.requested` or `authorization.required`, then `turn.waiting` with `on: "input"` and the open turn's `turnId`. After the answer or sign-in, the turn resumes with the next `step.started` for the same `turnId`, and only `turn.completed`, `turn.failed`, or `turn.cancelled` ends it. When you answer a question that belongs to a workflow tool or a subagent, the session you answer on emits `input.resolved` for it as it routes the answer down. While other relayed questions are still pending, it then emits `turn.waiting` with `on: "input"` again. If the workflow tool run that relayed a question or approval ends before anyone answers, that session emits `input.resolved` with `outcome: "cancelled"` for it. This covers the run's own `ctx.ask()` questions and requests from sessions it opened with `ctx.agent`. A cancelled turn does the same for every question or approval the session relays. A sign-in or tool approval the turn raises itself holds it the same way, also with `on: "input"`. A message from the same person steers the turn and cancels the request: a sign-in reports `authorization.completed` with `outcome: "declined"`, and an approval reports `input.resolved` with `outcome: "ignored"`. Messages from other people wait until the turn ends. Cancelling the turn ends both: a held sign-in reports `authorization.completed` with `outcome: "declined"`, and a held approval reports `input.resolved` with `outcome: "cancelled"`.
 
 ### Task events
 
@@ -225,6 +225,8 @@ A structured response matches any currently pending request by ID, not only the
 
 One delivery can answer requests from several batches. eve resumes approval-bearing batches in durable order and carries later answers forward until each batch can resume. If you answer only some approvals in a batch, eve saves those responses until the remaining approvals are answered. Meanwhile, unrelated messages can run tools and receive a completed reply. The saved partial responses neither block that reply nor trigger another model call after it.
 
+When steering interrupts pending model generation, the interrupted step still ends with `step.completed`, carrying `finishReason: "other"` and any usage the provider reported. The correction's `message.received` and the next `step.started` for the same `turnId` follow.
+
 Multiple steering messages retain their durable arrival order and may be folded into one input at the next boundary. A message accepted after turn settlement starts the next turn. See [message delivery and steering](./execution-model-and-durability#message-delivery-and-steering).
 
 ## Cancel the in-flight turn

package/docs/evals/cases.mdx

@@ -110,6 +110,7 @@ Every `t.session()` or `t.send()` creates a new independent conversation. Contin
 - `session.send(message, options?)` sends a follow-up on that session and waits for it to settle.
 - `session.start(message, options?)` starts a text turn and returns as soon as the server accepts it. The live turn exposes `.session`, `.sessionId`, `.waitForEvent(...)`, `.cancel()`, and `.result()`.
 - `session.cancel()` requests cooperative cancellation of that session's active turn. Both `accepted` and `no_active_turn` are successful outcomes.
+- `session.compact()` compacts that session's history between turns and waits for it to finish. It resolves to the captured events from `compaction.requested` through `session.waiting`, so assertions such as `.event("compaction.completed")` work on the result. It throws when the session is no longer active.
 - `session.sendFile(text, path, mediaType?)` attaches a local file as a data URL.
 - `session.agent(started).stream(options?)` follows a delegated child's stream through the parent with the eval client's credentials. Pass an `agent.started` event from that session. It also reaches children on another deployment, which `t.target.watchTurn(...)` cannot address.
 - `session.requireInputRequest(filter?)` records a gate, requires exactly one pending request, and returns it. Filters match tool name, action input, prompt, display, and option ids.

package/docs/extensions.md

@@ -210,11 +210,13 @@ Extension state belongs to the logical mount path (for example, `extensions/crm`
 
 ### Upgrade from package-scoped extension state
 
-Deployments before eve 0.69 stored extension state under package-prefixed keys, such as `acme-crm.requests`. When a session from one of those deployments hands off to a newer deployment, eve moves each package-prefixed value to the mount that uses that package. eve never resets that state during restore.
+Deployments before eve 0.69 stored extension state under package-prefixed keys, such as `acme-crm.requests`. When a session from one of those deployments hands off to a newer deployment, eve moves each package-prefixed value to the mount that uses that package.
 
-- The value moves only when exactly one mount uses the package and the extension still defines that state name. Otherwise eve cannot tell which mount owns the value, so the handoff is rejected and the session stays on its current deployment. Keep that deployment available until the session finishes, or start a new session on the deployment you want to use.
+- The value moves when exactly one mount of that package defines that state name.
+- When no mount of that package defines that state name, for example because the extension removed it or the package was renamed, eve drops the value. The target deployment's runtime logs show a `dropping unknown context key during deserialization` warning with the key.
+- When two or more mounts use the package and define that state name, eve cannot tell which mount owns the value, so the handoff is rejected and the session stays on its current deployment. Keep that deployment available until the session finishes, or start a new session on the deployment you want to use.
 - Older deployments cannot read sessions saved by a newer release, so a session that already moved does not hand back after a rollback.
-- Local context snapshots follow the same rule: an older snapshot restores when every saved state key still has an owner.
+- Local context snapshots follow the same rules.
 
 ### Use an extension in a workspace
 
@@ -368,6 +370,7 @@ At build time, eve checks the extension's generated capability metadata. If the
 ## What to read next
 
 - [Integrations](/integrations): browse ready-to-install extensions using the Extensions filter
+- [Code extension](/docs/code-extension): mount eve-code, the coding extension that ships in `eve`, and see its benchmark results
 - [Tools](/docs/tools): static tools, approval, and tool output
 - [Dynamic capabilities](/docs/guides/dynamic-capabilities): dynamic connections, tools, skills, and instructions
 - [Instructions](/docs/instructions): static and TypeScript instructions

package/docs/guides/client/streaming.mdx

@@ -173,7 +173,7 @@ The sign-in holds the turn open, and the stream emits `turn.waiting` with `on: "
 
 HTTP connections can end before a run does. The client reconnects from the number of events already consumed, so long turns continue without replaying events. By default, a turn response keeps reconnecting until it reaches a turn boundary or is aborted, including while the turn is paused for authorization. A manually opened `session.stream()` eventually stops after repeated empty streams when it can no longer make progress.
 
-Browser failures while reading a response body, including `TypeError: Load failed` and `TypeError: network error`, use the same reconnect policy. Invalid stream events still fail the read.
+Browser network failures use the same reconnect policy, both when opening a stream (`TypeError: Failed to fetch`, `TypeError: Load failed`, or `TypeError: NetworkError when attempting to fetch resource.`) and while reading a response body (any `TypeError`, such as `TypeError: network error`). Invalid stream events still fail the read.
 
 If your consumer persists events, key on `event.meta.id`. It is stable across reconnects and rewinds, so an overlapping replay is safe to ingest twice. See [the event envelope](../../concepts/sessions-runs-and-streaming#the-event-envelope).
 

package/docs/guides/dev-tui.md

@@ -98,7 +98,9 @@ Type a message and press `Enter` to send it. When the agent asks a question or r
 
 The activity line shows **Thinking** while the model reasons or waits to respond, **Generating** while it writes a response or tool input, and **Running** while tools execute. A blinking dot and elapsed time indicate progress, with token counts shown when available. While [tasks](../tools/tasks) work, the drawer header replaces this line: it shows the parent's current activity, task count, and turn elapsed time without token counts. **Waiting** means the parent is waiting on work; **Working** appears without a turn timer when tasks remain active between turns.
 
-A task, such as a call to a subagent, writes one line to the transcript when it starts and one when it finishes, fails, or is stopped. The finished line names how long the task took and, for a subagent, what it did, such as `Read 3 files, Ran 2 commands`. Task starts use the same tool-call styling as synchronous calls. While tasks work, an activity drawer above the prompt shows each task's name, current activity, and elapsed time without repeating its launch prompt. Subagents use labels such as `subagent(self-modification)`, with elapsed time beside the name and the latest observed tool grouped beneath an elbow. The tool remains visible between calls rather than switching to a starting placeholder. During questions and approvals, activity stays visible above the request with a shared divider when screen space permits; the request takes priority on small terminals. Background work started by a followed subagent appears beneath that subagent; deeper work uses an ownership path instead of further indentation. The panel caps its height and prioritizes tasks needing approval when work overflows. The UI does not show the model's own `task_wait` and `task_cancel` calls; their effect appears as the **Waiting** header and a stopped task's line.
+A tool call shows the tool's own `label`, or eve's copy for built-in tools such as `Read README.md`. Any other call shows a readable tool name without its extension or connection prefix, such as `List issues` for `linear__list_issues`. Approval prompts show the exact tool name unless the tool provides a title.
+
+A task, such as a call to a subagent, writes one line to the transcript when it starts and one when it finishes, fails, or is stopped. The finished line names how long the task took and, for a subagent, what it did, such as `Read 3 files, Ran 2 commands`. Task starts use the same tool-call styling as synchronous calls. While tasks work, an activity drawer above the prompt shows each task's name, current activity, and elapsed time without repeating its launch prompt. Subagents use readable labels, such as `subagent(stock price)` for a `stock-price` subagent or `subagent(worker)` for the `code__worker` subagent of the code extension, with elapsed time beside the name and the latest observed tool grouped beneath an elbow. The tool remains visible between calls rather than switching to a starting placeholder. During questions and approvals, activity stays visible above the request with a shared divider when screen space permits; the request takes priority on small terminals. Background work started by a followed subagent appears beneath that subagent; deeper work uses an ownership path instead of further indentation. The panel caps its height and prioritizes tasks needing approval when work overflows. The UI does not show the model's own `task_wait` and `task_cancel` calls; their effect appears as the **Waiting** header and a stopped task's line.
 
 The prompt stays open while the agent works, including turns started elsewhere, such as a scheduled run. While a turn is running, `Enter` sends your message immediately as steering. Before assistant output begins, the runtime interrupts pending model generation and continues the same turn with your correction. Executing tools finish safely. After output begins, steering applies at the next workflow boundary and preserves streamed text.
 

package/docs/guides/dynamic-capabilities.md

@@ -55,7 +55,7 @@ export default defineAgent({
 });
 ```
 
-eve stages byte-backed `file` parts under `/workspace/attachments` before
+eve stages byte-backed `file` parts under `/workspace/.eve/attachments` before
 `step.started`, but keeps their media type in `ctx.messages`. When an image
 reaches the provider, vision models can process it and non-vision models reject
 it. eve does not reroute automatically. See [Inbound

package/docs/meta.json

@@ -20,6 +20,7 @@
     "---Integrate---",
     "install-integrations",
     "extensions",
+    "code-extension",
     "protocols/acp",
     "guides/client",
     "guides/frontend",

package/docs/sandbox/index.mdx

@@ -149,6 +149,19 @@ interface SandboxProviderResourceTree {
 
 Docker and microsandbox mount the compiled trees read-only under `/eve/resources`, copy workspace seeds into writable `/workspace`, and expose skills read-only where possible. Vercel's snapshot environment writes workspace and skill contents before capturing its snapshot. Custom providers decide whether to upload, mount, or write each tree, but must expose the final target paths before authored preparation runs.
 
+## Inbound attachments
+
+eve writes byte-backed files that reach the agent into the sandbox under `/workspace/.eve/attachments/` and keeps only a reference in session history. This covers files attached to user messages and files that tools return to the model with `toolOutputPart.file` or as MCP image, audio, and blob content.
+
+Before every model call, eve reads the referenced files back from the sandbox:
+
+- An image up to 3 MiB or a PDF up to 20 MiB attached to a message reaches the model as a file. Larger files and other types reach the model as a text reference, such as `Attached file /workspace/.eve/attachments/<hash>/report.csv (text/csv)`, that the agent can open with `read_file` or `bash`.
+- A file returned by a tool always reaches the model as a file.
+
+If a referenced file is missing, or its bytes no longer match what eve staged because something in the sandbox overwrote it, the model receives a `FileNotFound` note in its place.
+
+Each call sends the same bytes for the same file, so the model still sees attachments from earlier turns and the provider's prompt cache stays valid. Compaction replaces files in older tool results with their text reference. The `read_file` tool shows PNG, JPEG, GIF, and WebP files up to 3 MiB to the model as images, so the agent can look at an image again after compaction.
+
 ## Custom providers
 
 Define a provider with `defineSandboxProvider()` from `eve/sandbox/provider`. The five generic parameters describe environment options, live options, the prepared artifact, minimal serialized session state, and the provider-specific sandbox session type:

package/docs/tools/overview.mdx

@@ -307,9 +307,11 @@ export default defineTool({
 
 The `toolOutput.text` and `toolOutput.json` builders construct the other two output shapes; hand-written literals remain valid everywhere.
 
-File payloads must be base64 strings — raw bytes (`Uint8Array`, `Buffer`) are rejected because they do not survive eve's durable JSON boundary. Keep payloads small: a content-part image is persisted in session history and re-sent on every subsequent model call, and eve warns above 3 MiB. Sending image parts to a model without vision support fails with that provider's error, the same as image parts in user messages.
+File payloads must be base64 strings — raw bytes (`Uint8Array`, `Buffer`) are rejected because they do not survive eve's durable JSON boundary. eve warns above 3 MiB. Sending image parts to a model without vision support fails with that provider's error, the same as image parts in user messages.
 
-When older turns are compacted, file payloads are dropped from the summary and replaced with a text stub naming the file and media type — the model cannot re-see a compacted image. Content parts are for "look at this now"; if the agent may need an artifact again later, write it to the [sandbox](/docs/sandbox) and return its path.
+eve writes each returned file to the session sandbox and keeps only a reference in session history, so the file's bytes are not stored again on every workflow step. Every later model call sends the same file, which keeps it visible on later turns and keeps the provider's prompt cache valid. See [Inbound attachments](/docs/sandbox#inbound-attachments). Compaction counts an image at roughly what providers bill for it rather than its base64 length.
+
+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 files up to 3 MiB to the model as images, so the agent can open a compacted image again.
 
 Do not return secrets, credentials, unnecessary personal data, or unbounded sensitive content from tools. Filter, minimize, and redact tool outputs before returning them.
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "eve",
-  "version": "0.70.1",
+  "version": "0.70.3",
   "private": false,
   "description": "Filesystem-first framework for durable backend AI agents that run anywhere.",
   "keywords": [
@@ -547,12 +547,12 @@
     "@vercel/otel": "2.1.3",
     "@vercel/sandbox": "3.3.0",
     "@vercel/sdk": "1.28.8",
-    "@workflow/core": "5.0.0-beta.57",
-    "@workflow/errors": "5.0.0-beta.24",
-    "@workflow/serde": "5.0.0-beta.2",
-    "@workflow/world": "5.0.0-beta.39",
-    "@workflow/world-local": "5.0.0-beta.48",
-    "@workflow/world-vercel": "5.0.0-beta.52",
+    "@workflow/core": "5.0.1",
+    "@workflow/errors": "5.0.1",
+    "@workflow/serde": "5.0.0",
+    "@workflow/world": "5.0.1",
+    "@workflow/world-local": "5.0.1",
+    "@workflow/world-vercel": "5.0.1",
     "ai": "^7.0.105",
     "chat": "4.41.0",
     "chokidar": "5.0.0",