eve

Summary ended every session 30 days after creation, even sessions in daily use. It exists to bound storage for abandoned sessions, not to cap active ones. This PR makes it an idle timeout: the window restarts each time a turn settles, so only idle sessions expire. When an idle session that keeps its run data expires, the next channel message at its current address starts a fresh session whose names the expired one. Instructions can then read the earlier conversation, as they already do for stranded sessions. How it works: Idle timeout: each owner keeps one durable timer. When the timer fires and the window has not ended, the owner arms a new timer for the new deadline. Active sessions cost one timer per window, not one per turn. A successor owner starts its window at boot, right after the delivery or compacting turn that moved it, so compaction handoffs no longer carry a deadline. Input that is already waiting when the timer fires also counts as activity, so a delivery accepted behind the timer is not lost. Expiry link: an expired session leaves a retained Workflow hook () on its current continuation address, with its session ID as metadata. Session creation at that address reads the link. The new owner releases the link once it holds the address, so a later reset does not bring back the old conversation. The read is best-effort. A failed or unreadable read starts the session without a predecessor, and the new owner still releases the link. Scope boundaries: Zero-retention sessions and resets leave no link. With the default trace policy, private and unknown-audience sessions outside development use zero retention. Their data is deleted when they end, so they have nothing to continue. turns links on for them. The e2e fixture sets this option. Worlds without and skip links. A stranded session that its timer ends still leaves no link. A session never expires while a turn is open, including a turn held for working tasks or human input. This was already true under the absolute deadline. The window counts from when that turn settles. Validation , , , , : pass. : 114 files, 1073 tests pass. A fresh-context review found nothing critical. This PR fixes the important findings: the fixture retention, the best-effort lookup, and waiting input as activity. Integration, scoped to the touched files: (29/29, run twice), , , , and all pass. The new idle-extension and predecessor-link tests fail when each behavior is disabled. So does the link-release assertion. The e2e eval now asserts that the replacement session names the expired one. It runs in CI only. Checklist [x] I added tests and documentation where relevant [x] I added a changeset if this touches the published package [x] DCO sign-off passes for every commit ()

Summary The default tool intentionally has no model input, but some apps want a separate model-facing variant that selects a model for each root-copy task. This adds the opt-in workflow tool with . It uses the same lifecycle as the default tool, including receipts, results, cancellation, and continuation, while the default and declared agent tools remain unchanged. Depends on #5087, which adds the model override used by this custom tool. Validation — 18 tests passed Targeted on changed TypeScript and eval files Added ; e2e evals run only in CI — the changed code passes; the command remains blocked by three pre-existing symlinks in the untracked local tree Checklist [x] I added tests and documentation where relevant [x] I added a changeset if this touches the published package [x] DCO sign-off passes for every commit ()

Summary Slack Code lets an agent open a dedicated code channel for multi-step work, and Slack expects the agent to decide when to open one. eve cannot do this today: Slack sessions are keyed by thread and replies are always threaded. This PR adds a research plan for code channel support in the existing , in three phases: serve code channels, fork a thread into a code channel, and code channel surfaces (context bar, views, archive). Stacked on #5096. Forking is a workflow tool that creates the code channel and starts its session with and the thread's transcript as , following #5096's fork pattern. It can ship on #5096 as it stands with at-least-once delivery. Making it exactly-once and safe against a message that arrives before the seed needs on handles with a first message, which #5096 defers until a caller needs it. The plan also proposes a receive target for the Slack channel, a size check against Workflow payload limits, and lineage as a follow-up. This replaces #5092, which was stacked on an earlier revision of #4477. This is a plan only. It changes no code. Validation on the new file. Checked the plan against #5096: workflow tool semantics (named channels, at-least-once , deferred ), the fork pattern's transcript read, and Slack's default auth attributes (, , ). Slack API details come from Slack's public Slack Code and code channel lifecycle docs. Checklist [ ] I added tests and documentation where relevant [ ] I added a changeset if this touches the published package [ ] DCO sign-off passes for every commit ()