Changelog

Your assistant's email address used to take only your own mail. It now takes anyone's, so people and other agents can write to it. Mail from someone else never lands in your own thread with it: each sender's mail gets a conversation of its own.

An agent's push is checked before it lands: the default branch only fast-forwards and can't be deleted. A branch an agent rewrites or deletes is kept for 30 days; list them with Repo.backups and make one a branch again with Repo.restore_backup.

Moving an agent between Claude Code, Codex, OpenCode, OpenClaw, and Hermes used to end the thread it was on. Your next message started a new conversation with the recent turns pasted in as background. The conversation now moves into the harness you picked and carries on: the same thread, with each tool call still paired to what it returned, so the agent resumes where it left off rather than reading a summary of it.

• Any of the five CLI agents can hand a conversation to any of the others. The built-in LLM agent keeps its history in NoClick rather than in a session store of its own, so switching between it and a CLI agent still carries the recent turns across as context, about 4,000 characters of them, trimmed from the oldest end.
• Picking a thread in History now only opens it. It used to set the agent's Model to whatever that thread last ran on, changing the model you were about to run without telling you. The model stays the one you picked, and your next message runs it on the thread you opened.
• History rows no longer carry a tag naming the harness a thread ran on.
• The first message after a harness switch starts a new sandbox, so it takes longer than a follow-up. Messages after it are back to warm-sandbox speed.

A trigger wired into an agent used to hand it everything the service sent. A Slack message arrived as the whole delivery around it: verification tokens, authorization blocks, and a second copy of the text in Slack's own block format. The agent now reads a short account of what happened instead: the service and the kind of event, who it came from and where, the content itself, and the IDs it needs to reply in the right place.

• The triggers agents are usually wired to each write their own account of an event: Slack, Discord, Telegram, WhatsApp, inbound email, Gmail, Outlook, GitHub, GitLab, Linear, Jira, Notion, Trello, Asana, ClickUp, monday, Google Calendar, Forms, Sheets and Drive, Typeform, HubSpot, Shopify, Zendesk, Intercom, Stripe, Calendly, PagerDuty, Sentry, PostHog, Datadog, Honeycomb, Mailgun, Resend, Loops, schedules, and plain webhooks. Any other trigger gets the general shaping: the delivery wrapper opened, empty and internal fields dropped, and the rest held to a readable size.
• In the agent's chat, a turn that a trigger started is shown as the message that started it, laid out the way that app lays it out, under a caption naming the app, the node's label if you gave it one, and the trigger, for example Slack · Support channel · On app mention. Where a message view does not fit, such as a schedule tick, the account the agent read is shown with the event itself behind an Event payload toggle.
• The thread takes its name from the event, so the history list reads as the channel or the sender the message came from. Your standing instructions stay in the Message field, rather than appearing in the chat as a message you never sent.