eve 0.70.2 → 0.71.0

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

@@ -38,6 +38,23 @@ eve add tool/bash
 export { default } from "eve/tools/bash";
 ```
 
+`bash` waits up to 30 seconds for a command. A command that finishes in time returns `status: "completed"` with `exitCode`, `stdout`, `stderr`, and `truncated`. A command that is still running keeps running in the sandbox as its own process group and returns `status: "running"` with:
+
+- `pid`: the process group id
+- `outputDirectory`: a directory under `/tmp/.eve/jobs/`
+- `stdout`, `stderr`, and `truncated`: the output so far
+- `message`: instructions for the model
+
+The command keeps writing to `stdout` and `stderr` files in `outputDirectory` and writes its exit code to an `exit` file when it finishes. The model checks on or stops it with ordinary shell commands in later `bash` calls, so the tool's approval policy applies to them:
+
+```sh
+tail /tmp/.eve/jobs/3f9a1c2e/stdout   # latest output
+cat /tmp/.eve/jobs/3f9a1c2e/exit      # exit code, once the command has finished
+kill -- -4312                         # stop the command's whole process group
+```
+
+The command keeps running across turns until it exits, the model stops it, or the sandbox stops. Its output files stay in the sandbox until the sandbox stops. Cancelling a turn stops a command that has not yet returned `running`. The `just-bash` provider has no background processes, so it runs every command to completion.
+
 Override its description, approval policy, or executor by wrapping the exported definition:
 
 ```ts title="agent/tools/bash.ts"

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

@@ -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/extensions.md

@@ -370,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/memory/custom-provider.md

@@ -143,7 +143,10 @@ authored tools.
 
 A tool closes over the locked scope for the current turn, so it cannot be
 redirected to another tenant or caller by the model. eve keeps each tool
-callback replayable after a process restart or redeployment.
+callback replayable after a process restart or redeployment. On replay, eve
+calls `tools()` again with the captured `memory`, `turn`, and session context.
+`messages` is the history the current process resolved the turn's tools with,
+so after a mid-turn restart it also includes the turn's earlier tool results.
 
 ## Lifecycle
 

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

@@ -158,6 +158,8 @@ 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

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "eve",
-  "version": "0.70.2",
+  "version": "0.71.0",
   "private": false,
   "description": "Filesystem-first framework for durable backend AI agents that run anywhere.",
   "keywords": [