AgentOS 2026.8.17

A scheduling-and-sessions release: cron jobs can be edited instead of rebuilt, they can name where they announce, and sessions can be renamed from every surface.

Cron jobs are editable

The in-agent cron tool can finally change a job in place. Previously the only strategy available to an agent in chat was to add a replacement and remove the original — which deleted the job the user wanted to keep and reset every setting the re-create did not name: an agent_turn fell back to reminder, a job pinned to Asia/Bangkok moved to UTC, its tool policy was dropped, and its output started landing in the current chat instead of the channel it reported to.

• action="update" patches a job in place, keeping its id.
• action="get" returns the full record — kind, tz, schedule, session target, delivery, tool policy, wake mode, timeout, script fields — and names a webhook's host without disclosing its URL path or token.
• clone_from on add inherits every setting of the source job and overrides only what is passed.
• name gives a job a display name, so it no longer has to be its own prompt.

Jobs carrying a script or tool_policy.elevated stay operator-only to clone or update, and a channel caller cannot clone or rewrite a job that reports to a destination its own chat cannot address. (#309)

Cron jobs can name where they announce

Both add and update take a delivery object — mode (origin, channel, or none), channel_name, channel_id, account_id, thread_id, and best_effort. "Every weekday at 9, post the digest to the ops group" no longer has to be created in the chat that will receive it, and moving an existing job's announcement is an edit rather than a rebuild: a repoint keeps the job's id, run history, ws_topic (so existing websocket subscribers stay attached), and failure destination.

The destination is validated when the job is saved, not when it fires. An unconfigured channel name, an AgentOS session key passed where the provider's chat id belongs, or a destination paired with a mode that cannot route to it are all refused with an error naming the problem — silently falling back to the calling chat is what made a misdirected job look like a working one. Omitting delivery keeps the existing behaviour exactly.

Choosing a channel requires an interactive CLI or Web caller and a session_target other than main; webhook delivery and failure destinations remain CLI-, Web-, and RPC-only. (#310)

Sessions can be renamed

A new sessions.rename RPC sets or clears a session's display_name, and every surface reaches it:

• agentos sessions rename <id> "<name>" (--clear drops it)
• /rename <name> in CLI chat — gateway and standalone — and in chat channels
• Click-to-edit on a row in the Web UI session list
• Rename session in the Chat header ⋯ menu: Enter saves, Escape cancels without closing the menu, an empty value clears the name. Once a session has one, the header chip shows the name instead of the key (the key stays in the tooltip and in Copy session key), and the session switcher lists renamed sessions by name with the key underneath.
• The new session_rename tool, so "call this one X" works as a prompt. It can rename only the session it is running in, and reports rather than silently succeeding when storage cannot persist the change.

agentos sessions list grows a Name column and a --search/-q filter matching name, key, subject, or model; the Web UI switcher's search now matches the name and derived title as well as the key. Names normalize in one place (agentos.session.naming): whitespace collapses to a single line, control characters are dropped, the value is capped at 120 characters, and an empty name clears the label so the derived title takes over. Renames resolve a target the same way /resume does, so a session can be renamed by its current name — an exact name beats a prefix match, so naming a session agent no longer collides with every session key. No migration is required. (#248)

Fixed

• Rescheduling a one-shot cron job onto a recurring expression no longer leaves delete_after_run set, which made the edited job delete itself after its first fire.
• Converting a job away from agent_turn now drops a stranded tool_policy.elevated instead of persisting a combination cron add refuses to create.
• A tool_policy sent alongside a kind change is validated against the new kind rather than the outgoing one.

All three live in SchedulerOps.update, so the cron.update RPC and the Web UI edit flow get them too.

Install

uv tool install --python 3.12 "use-agent-os[recommended]==2026.8.17"

Full changelog: https://github.com/use-agent-os/agent-os/blob/v2026.8.17/CHANGELOG.md