eve 0.41.0 → 0.43.0

package/docs/guides/remote-agents.md

@@ -114,9 +114,17 @@ export default defineRemoteAgent({
 });
 ```
 
-The create-session request then carries the parent turn's `session.auth.current` and `session.auth.initiator` as a `forwardedPrincipal` body field (`initiator` is optional on the wire; when absent, the receiver seeds both from `current`). Only principal metadata crosses the wire — never tokens or credentials. The receiving deployment mints its own per-user credentials through its own connections.
+The create-session request carries the parent turn's `session.auth.current` and `session.auth.initiator` as a `forwardedPrincipal` body field (`initiator` is optional on the wire; when absent, the receiver seeds both from `current`). Every continuation carries only that turn's `session.auth.current`; the remote session keeps its original `auth.initiator`. Only principal metadata crosses the wire — never tokens or credentials. The receiving deployment resolves its own per-user credentials through its own connections.
 
-Forwarding is explicit on both sides. The receiver names which forwarders it trusts with `eveChannel({ trustedForwarders })` (see [Auth & route protection](./auth-and-route-protection#accepting-forwarded-identity-from-another-deployment)); a receiver that refuses the forwarder — or has no `trustedForwarders` at all — rejects with a 403 and the dispatch fails. One caveat: a receiver on an eve version that predates principal forwarding drops the unknown field and runs the session as your app's service identity (per-user connections there fail with `principal_required`), so upgrade both deployments together when enabling forwarding. When the dispatching turn has no auth at all, the field is omitted and the call proceeds on transport trust alone.
+This makes caller authority turn-scoped even when the remote child session is persistent. If Alice starts the child and Bob later continues it, the follow-up runs with Bob as `auth.current`, not Alice. If the parent turn's auth is `null`, a local child clears `auth.current`, while a remote child uses the freshly verified transport principal; neither inherits Alice. eve's in-step bearer cache is also keyed by the resolved principal and is not serialized across steps. The external authorization provider may preserve each user's server-side OAuth grant, but a later turn can resolve only the grant belonging to its own `auth.current` principal.
+
+Identity forwarding does not make a persistent session private to one caller. Conversation history, tool outputs, and other child-session state still persist. If those values must not be visible across users, give each user a distinct child session or enforce that ownership at the application boundary.
+
+Forwarding is explicit on both sides. The receiver names which forwarders it trusts with `eveChannel({ trustedForwarders })` (see [Auth & route protection](./auth-and-route-protection#accepting-forwarded-identity-from-another-deployment)); a receiver that refuses the forwarder — or has no `trustedForwarders` at all — rejects with a 403 and the dispatch fails.
+
+> ⚠️ **Upgrade both deployments before resuming persistent remote sessions.** A sender with continuation forwarding includes `forwardedPrincipal` on each authenticated follow-up. A receiver that supports forwarding only on session creation rejects that continuation with HTTP 400. eve does not retry without the field because that would run the follow-up as the transport service principal and silently change caller authority. The parent retains the child handle after this failure, so you can retry the same session after upgrading the receiver.
+
+A receiver on an eve version that predates all principal forwarding may instead drop the unknown field and run the session as your app's service identity; per-user connections there fail with `principal_required`. On remote requests where the dispatching turn has no auth, the field is omitted and the call proceeds on transport trust alone.
 
 ## How remote dispatch and callbacks work
 

package/docs/tools/overview.mdx

@@ -56,6 +56,25 @@ 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
 can retry a step and replay overlapping snapshots.
 
+### Experimental background execution
+
+`defineTool({ execution: "background" })` receives a third `task` argument. Returning a normal
+value completes the durable task with that value. Returning `task.delegated({ executor, receipt })`
+returns a `working` receipt immediately while an external executor continues the task.
+The root agent must enable `experimental.tasks`; eve rejects background tools at build time otherwise.
+
+This contract currently supports framework-owned task executors, including local and remote
+subagents when `experimental.tasks` is enabled. After delegating, an in-process executor reports
+progress with `task.send({ kind: "update", message })` and the terminal result with
+`task.send({ kind: "complete", data })` (or `fail` / `cancel`). `send` is not restart-safe — an
+in-memory callback dies with the process — so the cross-process executor wire remains
+framework-owned and is not yet a stable authored-tool API.
+
+Each task-triggered parent turn includes runtime-authored state for tasks started by the same
+parent turn. The model is instructed to keep related intermediate results silent while that state
+contains pending tasks. Once every related task is terminal, the state includes their outputs so
+the model can combine the useful results.
+
 ### The `ctx` parameter
 
 `execute` gets a `ctx` carrying the runtime accessors:

package/package.json

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