CHANGELOG.md

# Changelog

What changed, for somebody deciding whether to upgrade. Written for the person running OpenBot, not
for the person who wrote the commit: a line belongs here when a deployment behaves differently
afterwards, and does not when only the code moved.

Newest first. `Unreleased` is what is on `main` and not yet tagged.

## Unreleased

**Before upgrading.** Sixteen things change for an existing deployment:
- Bots now share one computer per person instead of each having its own. Migration
  `0069_isolated_bots` adds `agent_profiles.isolated`, off for every existing Bot. With the
  supervisor (laptop, Desktop, Compose), a person's computer is created the first time one of their
  Bots acts, as `<namespace>-computer-person-<id>`, and the supervisor stops the old per-Bot containers
  when it starts, keeping their volumes. A private Bot's logins are copied into its owner's computer
  once; public Bots, the built-in ones included, sign in again once, because their old logins were
  shared by everyone who used them. Helm `shared` moves private Bots' profiles the same way. On Helm
  `sandbox` nothing is copied, so private Bots sign in again once there too. With the supervisor, a
  private Bot's files come along the same way, into its folder on its owner's computer; a public
  Bot's old files stay in its old volume. Old per-Bot volumes are left in place; remove them when you
  are satisfied. Helm's computer memory defaults rise to a 2Gi request and an 8Gi limit.
- A hosted computer's browser is now headed by default. It uses a little more memory than headless
  did; set `COMPUTER_BROWSER_MODE=headless` (Helm: `computers.browserMode: headless`) to keep the old
  behaviour.
- Migration `0054_memory_on_intelligence` adds two columns to `personal_memories`. On a deployment
  entitled to Intelligence memory, the memory sweep then copies existing reviewed, switched-on memories
  into Intelligence, a few people at a time each minute; it is idempotent and safe to interrupt.
  Memories awaiting review, paused or forgotten stay local until that changes.
- With nothing saved under Admin → Automatic Learning and no `CPK_INTELLIGENCE_LEARNING_CONTAINER_ID`,
  the server assigns its Intelligence project's `openbot` container once it exists, and `scripts/start.sh`
  creates that container. A saved setting, including off, is never changed;
  `OPENBOT_LEARNING_AUTO_ASSIGN=false` (Helm: `config.learning.autoAssign: false`) prevents it.
- Migration `0055_default_opt_outs` adds one table, `default_opt_outs`, where a person's removal of a
  default memory source or background research is recorded. Memory sources and background research
  then switch on for each person and Bot that talk (below), so expect background research turns, and
  their model tokens, four hours after a person first talks to a Bot. Only removals from now on are
  recorded: a source or research setting somebody deleted before the upgrade left no trace, so it
  comes back on their next conversation with that Bot (one they turned off and kept stays off).
  `OPENBOT_MEMORY_SOURCE_DEFAULTS=false` and `OPENBOT_PROACTIVE_DEFAULTS=false` (Helm: `config.memory.*`)
  prevent it.
- Migration `0056_sign_in_code_step` widens the check on `sign_in_requests.status` to allow
  `code_required` (below). A server and a computer must be upgraded together: an older computer has
  no `/sign-in/code`.
- Migration `0060_app_access_requests` adds one table, `app_access_requests`, where a person's
  request for an administrator to switch on a work app, grant it to a Bot, or connect a Shared app's
  team account is kept, with who answered it and when. It starts empty and nothing is backfilled.
- Migration `0066_recorder_extension` adds six tables for the OpenBot Recorder and each person's own
  Learning space (below): `recorder_connect_codes`, `recorder_connections`,
  `recorder_trajectory_bindings`, `learning_person_spaces`, `learning_skill_sharing` and
  `learning_open_skills`. Nothing existing changes, and the tables stay empty until somebody
  connects a browser or changes Settings → Learning.
- The CopilotKit runtime moves to 1.79.1. A built-in Bot whose `openai/...` model is reached
  through an `OPENAI_BASE_URL` that is not OpenAI or Azure now calls that endpoint's Chat
  Completions API (`/chat/completions`) instead of the Responses API. That is what most
  OpenAI-compatible endpoints serve, so Bots behind one of them now work; a gateway that also serves
  the Responses API loses Responses-only features, such as reasoning summaries, without an error.
  `COPILOTKIT_OPENAI_API=responses` keeps the Responses API (`chat` forces Chat Completions); any
  other value is an error when a built-in Bot runs. Deployments on OpenAI or Azure are unchanged.
- Migration `0067_recorder_activity` adds two nullable columns to `recorder_connections`, where each
  OpenBot Recorder's latest recording activity is kept. Nothing existing changes.
- Migration `0061_suggestion_superseded` widens the check on `proactive_suggestions.status` to allow
  `superseded` (below). Open suggestions from before the upgrade stay open until that Bot's next
  research run replaces them.
- Migration `0062_action_policy_labels` adds a `labels` column to `action_policies`, defaulting to
  empty. Existing boundary rules keep working and show as "Custom rule" until somebody names them.
- On Helm's `shared` computer and the docker-compose `agent-computer`, each Bot's files now live in
  `computers/<Bot id>` on the workspace volume (below). Files saved before the upgrade stay at the
  root of the volume, where no Bot sees them; move them into a Bot's folder to give them back.
- With `OPENAI_BASE_URL` set to a host that is not OpenAI or Azure, `openai/...` models now use the
  Chat Completions API rather than the Responses API (below). Set `COPILOTKIT_OPENAI_API=responses`
  to keep the old behaviour.
- Interfaces a Bot drew before the upgrade (A2UI 0.9 surfaces) no longer draw when a conversation is
  reopened; the messages around them stay. New ones use A2UI 1.0 (below).
- A computer now closes browsers nobody is using, least recently used first, when its memory
  reaches 85% of its limit, and closes a Bot's background tabs after ten minutes untouched (below).
  In the all-in-one image that share counts the database and the API server too.
  `COMPUTER_MEMORY_HIGH_PERCENT=0` and `COMPUTER_TAB_IDLE_MS=0` (Helm: `computers.memoryHighPercent`
  and `computers.tabIdleMs`) keep the old behaviour.

### A computer closes browsers nobody is using when its memory runs high

A computer runs one browser for each Bot that is browsing, and the only limits were a count and half
an hour untouched. Neither looked at memory, so a few heavy pages could take a container past its
memory limit well under the count, and the kernel then killed processes without regard to which Bot
was busy. On Kubernetes it kills everything in the container at once, so every Bot's browser closed
together and nothing could reach the computer until it came back. A computer now reads its own
memory the way the kubelet does (the working set, which leaves out the file cache the kernel can
drop), before it starts a browser and once a minute. At or above 85% of its limit it closes browsers
one at a time, least recently used first, until it is under 75%, so the next launch does not cross
the line again straight away. Launches that arrive together share one pass rather than closing a
browser each. A Bot whose browser was closed starts again where it left off on its next step, still
signed in, because its profile is on disk.

Only a browser nobody is using is closed. Never closed for memory: the browser being started, the
most recently used one, any browser used in the last minute (a Bot between two steps asks for
nothing while its model works out the next), a person's own browser, cloud or native, whose Recorder
session would end, and the browser of a Bot whose wheel a person holds or has been asked to take.
When every browser is in use, none is closed.

This is a check, not a guarantee. Memory is read before each launch and once a minute, so a page
that grows between two checks can still run the container out of memory. A container with no memory
limit is measured against the machine's memory, and a computer outside a container, such as OpenBot
Desktop's, closes nothing for memory. In the all-in-one image the database and the API server run in
the same container as the browsers, and the share counts them too. That is deliberate: the kernel's
out-of-memory kill counts everything in the container and can take the database down, and closing a
browser nobody is using first is how the database is protected. Each close is logged as
`computer-browser-closed-for-memory` with the working set and the limit in bytes.
`COMPUTER_MEMORY_HIGH_PERCENT` (Helm: `computers.memoryHighPercent`) sets the share where closing
starts, and `0` switches it off.

The tabs a Bot leaves behind are closed too. A Bot always works in its newest page, so an older tab,
such as the page a sign-in popup was opened from or a link a site opened in a new tab, is one it
cannot go back to, and it held memory for as long as the browser stayed up. A background tab that
nothing has used, navigated or brought to the front for ten minutes is now closed. The page the Bot
is on is never closed, and neither is any tab of a person's own browser or of a Bot whose wheel a
person holds. `COMPUTER_TAB_IDLE_MS` (Helm: `computers.tabIdleMs`) sets the time, and `0` keeps them.

Through Helm, `computers.browserIdleMs` and `computers.maxBrowsers` now reach the computer as
written. An hour (`browserIdleMs: 3600000`) used to render as `3.6e+06`, which the computer ignored
for its default of thirty minutes, and `browserIdleMs: 0` (keep browsers open) was dropped. All four
of these settings now also reach the computers `computers.mode: sandbox` makes, which had none of
them.

### A conversation opens at the bottom and stays still while a Bot writes

Opening a conversation shows its newest messages at once, already at the bottom, instead of loading
and then gliding down; a long one draws older messages as somebody scrolls up to them, without
moving what they are reading. Charts, tables, cards and decisions a Bot draws grow in place while
they stream, and no longer flash "not available" before they appear. A reply is revealed at a steady
pace, and the view follows it until the person scrolls up or selects some of it, and picks it up
again when they come back to the end or press the arrow. A rail beside a conversation has a mark
per turn: hovering one previews what was asked and answered, and choosing it goes there. Nothing
changes for a deployment.

### Generated interfaces use A2UI 1.0

With generative UI on, a Bot builds an interface from the A2UI 1.0 basic components instead of the
A2UI 0.9 ones. It's the same set of 18: text, images, icons, video, audio, rows, columns, lists,
cards, tabs, dividers, dialogs, buttons, checkboxes, text fields, date pickers, choice pickers and
sliders. They now take OpenBot's colours, radii and font, in light and dark. The gallery components a
Bot is granted are unchanged. `OPENBOT_GENERATIVE_UI=false` still switches it all off, on the server
as well as in the browser.

### CopilotKit 1.83

OpenBot now runs on CopilotKit 1.83.0 (`@copilotkit/runtime` and `react-core`, from 1.77.0) and
AG-UI 1.0.2 (`@ag-ui/core` and `@ag-ui/client`, from 1.0.1). A managed Intelligence project needs
nothing changed. A deployment whose `OPENAI_BASE_URL` points at an OpenAI-compatible gateway rather
than OpenAI or Azure now reaches `openai/...` models through Chat Completions; a gateway that only
speaks the Responses API needs `COPILOTKIT_OPENAI_API=responses`.

### Pick a skin: OpenDuet, OpenDots or OpenMuse

Settings → Preferences → Skin changes how OpenBot looks for you, and nothing about what it does.
Three skins draw the open-source templates' looks over OpenBot's own features: OpenDuet (one
phone-width column with Chat and Tasks), OpenDots (a rail, a sidebar of Bots with their avatars, and
the Bot's computer beside the chat) and OpenMuse (one Bot at the centre, with Chat, Activity, Ideas,
Goals and Apps). Every skin keeps your deployment's name from `brand.yaml`, OpenBot's own mark and
each Bot's own avatar; only the look changes. The choice is saved on your account, so it follows
you to every device, and changes nothing for anybody else. The templates' own features that
OpenBot has no server for, such as OpenDots' Spaces, OpenDuet's morning brief and OpenMuse's mail and
calendar, are not part of the skins.

### Each person's Bots share one computer, and a Bot can have its own

Every Bot used to get a computer of its own, which on a laptop or Desktop meant a container per Bot
running all the time, and meant everyone who used a public Bot shared its logins. Now all the Bots a
person uses run on that person's one computer, each with its own browser profile and folder, so a
login belongs to the person and the Bot, never to everyone who uses it. Tick **Isolated** when you
make a Bot, or in its Setup, to give it a computer of its own that keeps its logins; everyone who
uses that Bot shares that computer. Administrators decide who may: Admin → Enterprise → Isolated
Bots, on for everyone by default, and can be turned off for everyone or allowed for chosen roles and
groups. When it is turned off for somebody, their isolated Bots run on their own computer from the
next run, and the Bot's Setup says why. A deployment with one shared computer (Helm `shared`, or no
supervisor) cannot give a Bot its own, and the checkbox says so.

As is the industry standard for an always-on agent's computer, the Bots on a person's computer are
not kept from each other: a command any of them runs, a public Bot somebody else made included, can
reach anything on that computer. Each Bot still keeps its own browser profile there, which is
stricter than the standard, where a person's Bots share their sign-ins too. The admin Computers
screen says this, and a Bot that must be kept apart is made Isolated.

An isolated Bot's one computer is shared by everybody who uses it, so its Setup says, before it is
made public and while it is, that anything signed in to there is theirs too. Only the Bot's owner's
switch decides whether it may be isolated: an administrator ticking Isolated on somebody else's Bot
is refused when that owner lacks the switch, rather than saving a tick the Bot never ran with.

A person's computer runs a browser for each of their Bots in use, so Helm's computer now requests
2Gi of memory with an 8Gi limit (was 1Gi and 4Gi); `computers.resources` in values.yaml says how to
size it. Removing a person or deleting an isolated Bot leaves its computer until an administrator
resets it from Admin → Computers, which signs every Bot on it out of everything.

### The audit log reads like a log

Admin → Audit fills the window and runs the table across the whole pane, with the title, the views
and the search held in place while only the rows scroll. Each row shows the full date and time and a
mark for what happened, with blocked rows tinted red and actions that did not happen tinted amber.
The newest come first, and a press on When turns the order round. A search box and Outcome, Bot and
Started by buttons narrow the events already loaded, and the count says how many of them match. A
row about a Bot (a message routed to it, say) now names it under Bot.

### The desktop setup page does not freeze when it loads during an install

If the setup page loaded again while the desktop app downloaded local software, the window showed a
spinning cursor until the download finished. Its checks for a running OpenBot and for the last
failure now wait in the background, so the window keeps answering.

### Each Bot on a shared computer has its own files

A computer that serves many Bots kept one folder of files for all of them, so a note one Bot saved
was a file every other Bot could list and read. Each Bot now gets its own folder, and its commands
start there. Logins were already kept apart. This is on for Helm's `shared` computer and the
docker-compose `agent-computer`, and `COMPUTER_SEPARATE_WORKSPACES=on` turns it on for the
all-in-one image. A command can still read another Bot's folder, so a deployment that needs people
kept apart should give each Bot a computer of its own (`computers.mode: sandbox`).

### Every chart says where its figures came from

A chart a Bot draws now ends with a line naming what its figures were read from and when they are
from, such as "Sources: World Bank World Development Indicators · As of 2025". Figures a Bot charted
from its own knowledge, without looking them up, are marked "From the Bot's own knowledge. Not
checked against a source." Bots are told to look up figures that change over time before charting
them. In Slack and Teams the same line follows the chart in the reply. Charts already in a
conversation are drawn as before, with no such line.

### A Bot searches with its search tool, never its browser

Asked to search for something, a Bot could drive its browser to Google or another search engine
instead of using the search tool it held. With a search tool it now searches with that, and keeps
the browser for signing in, clicking through a site, filling in a form or opening a page the person
named. Without one it answers from what it knows, says it has not checked, and shows a card for a
search app (Parallel Search, Exa Search or Firecrawl) that the person can ask an administrator for.

### A computer that is starting says so, instead of showing a problem

Opening the Computer panel while a Bot's computer was asleep or starting showed "Can't show the
screen right now", and an action during a cold start was marked "didn't work". The panel now says
the computer is starting, or is off until the Bot next uses it, and shows a problem only when it
can't be reached or has gone two and a half minutes without a picture; a live screen being
reconnected shows a small "Reconnecting…" badge. An action turned away by a cold start reads "not
done yet" and the Bot is told to try again. Looking at the panel no longer wakes a sleeping computer,
a Bot says in one sentence what it is about to do before its first computer action, and a hosted
computer's cold start answers within 45 seconds, under a load balancer's usual 60-second idle
timeout. A Docker computer still booting its browser reads as starting once the supervisor is
upgraded too; an older supervisor works as before.

### A conversation shows who it is waiting on

When a Bot asks another Bot, the end of the conversation now shows that Bot's avatar and "Asking
Risk Analyst…" until the answer comes back; a routine firing into it reads "Market Scout is running a
routine…". A Bot whose address this deployment will not dial is reported at once, not after five
minutes of retries. The sidebar keeps the conversation lit while it waits, and both survive a
reload. In a shared conversation only the person whose Bot asked sees whom it asked; the others see
only that it is busy. Migration `0063_work_items_open_thread` adds one partial index to `work_items`.

### A Bot's owner can give it their own apps

The owner of a Bot can now let it use an app they connect for themselves, without an administrator:
from the app card ("Let Research Bot use your Gmail?"), under Your apps on the Bot's page, or on the
New Bot sheet, which offers their connected apps. Calls under such a grant always use the asking
person's own account, even on a published Team Bot, and an owner can take back only what they gave.
By default this covers apps each person connects for themselves and Routines; an administrator
decides per app on its page, and can switch it off for people with the "Give apps to their own Bots"
capability. Migration `0063_owner_app_grants` adds two nullable columns, `mcp_servers.owner_grants`
and `plugin_grants.granted_as`.

Where an administrator lets owners give a Shared app, an owner's grant works straight away: it lets
the people who can use the Bot (just the owner, or a Team Bot's audience) use the team account, with
no separate approval. Writes still ask first. Taking the app back, or the administrator switching the
app back to admins only, withdraws that. Migration `0064_owner_shared_audience` adds the nullable
`shared_use_approvals.approved_as`.

### An app card carries the task on once the app is ready

When a Bot stopped because it needed an app, and the person then connected it in another tab or an
administrator turned it on for the Bot, the card said "Ask again". It now sends "Gmail is ready now.
Please carry on." for the person, once, and the Bot picks the task back up; a card opened after the
change offers Continue instead. An administrator looking at the card gets the fix itself, "Turn on
and give it to Sales" or "Give it to Sales", which grants the app's read-only actions with the same
checks and trail as approving a request, or a link to the app's page where one press can't do it.

### Screens share one spacing, row and empty-state design

Every configuration screen now takes its spacing from the page frame: 32px under the title, 48px
between sections, rows at least 56px tall with dividers inset to the text. Rows draw their icon as a
glyph on a small tile, and a section with nothing in it says so with an icon, a title and, where
there is one, the button that adds the first thing. The root font size is the browser's 16px again,
with text kept on its 15px scale, so Tailwind sizes are their documented values.

### Adding a credential and a boundary rule are screens of their own

Add credential opens a page with a back button instead of a dialog. Boundaries is now a list of
named rules ("Bots may never…"); adding one starts from a template or a blank rule and can be tested
against recent activity before it applies, and each rule opens to what it has stopped lately.

### A Bot's page is shorter

Its In progress, Scheduled and Completed lists move to their own Activity page. The Bot's page keeps
what is running or scheduled, three at most, with a dot on anything under way, and shows its newest
three suggested next steps with the rest behind "Show more".

### Suggested next steps no longer pile up

Each research run replaces the open suggestions from the one before, and one with the same title as
a suggestion that is already open, or was dismissed in the last 30 days, is not suggested again. The
research is asked to suggest nothing when nothing needs doing, and not to name the Bot's tools.

### Pin or delete a conversation from its Bot panel

The gear panel in a conversation ends with Pin and Delete for that conversation.

### The @ menu shows each Bot's avatar, at the caret

On the home screen the @ menu opened away from the text, partly off the window; it now opens at the
caret. It is wider and shows each Bot's avatar beside its name.

### Filling in a form is no longer mistaken for paying

The built-in safety rules (paying or moving money, credentials, security settings) read the words a
Bot typed as well as where it typed them, so a Bot entering a CRM note about a customer's purchase
orders, or a press release's source such as Business Wire, was stopped with "Paying, purchasing or
moving money is always done by the person" and the step handed back to you. Typing is now judged by
the field, the page and the button: a card number field, a checkout page or a new password field
still goes to you, whatever is typed. A news wire (business, news or press wire) on a link or button
no longer counts as wiring money; wiring money still does.

### A page visit an approval rule covers now asks you

With an approval rule that asks before a Bot opens, reads or scrolls a page, the Bot was told the
action "was not started from a conversation that can ask you", did nothing, and said it could not get
an approval in this chat. The visit now waits on the approval card in the conversation, like a click
or a command does: Allow once opens the page and the Bot carries on, Deny tells the Bot it was
declined. Page visits no rule asks about still go straight to the computer.

### A Bot's browser step is no longer refused while it is being saved

Before your browser runs a click or a typed entry for a Bot, the server checks it against the copy
saved in the conversation. That copy is saved a moment behind, a piece at a time, and a check that
read it half saved refused the step with "That unanswered tool call is not saved in this
conversation" or "Supply a valid request", so a form the Bot was filling in could stop partway or ask
for your approval twice. The check now waits, as it already did for a step not saved at all, until
the step is saved whole.

### A Bot can choose from a dropdown

A Bot filling in a form in its browser could not set a dropdown (a native `<select>`, such as a CRM's
Industry or Stage). Typing into one waited until it timed out and was reported as a field that had
gone from the page, so the Bot took a fresh snapshot and tried the same thing again. Typing into a
dropdown now chooses the option it names, by the option's label or its value, and the page sees the
same change a person's choice makes. Text that names no option is refused with a message saying so.
A page snapshot now lists each dropdown's options and the one it shows, so the Bot can see what it
may choose and what is already chosen.

### A Bot carries on after a browser step fails

When a click, typed entry or key press the Bot made in its browser failed, the Bot's turn ended on
the spot: the step showed "Didn't work" and the Bot said nothing more. The failure now reaches the
Bot like any other result, so it can take a fresh snapshot, try another way, or tell you what
stopped it. A refused step reads as a refusal the Bot can explain.

### The computer image is about a fifth smaller to download

The `openbot-agent-computer` image carried two copies of Chromium: the full browser it runs, and
Playwright's separate headless shell, which it never starts. Every launch names a Chromium channel,
and Playwright runs the full browser for a named channel even with `COMPUTER_BROWSER_MODE=headless`.
The image now installs only the full browser and drops the package cache left from installing it.
The download falls from 537 MB to about 423 MB on arm64 and from 520 MB to about 411 MB on amd64.
Unpacked, the image is about 375 MB smaller on arm64 and 296 MB smaller on amd64. The all-in-one `openbot` image installs the same browser the same way and shrinks by about
as much. The browser and its behaviour are unchanged. On a desktop install the computer is the
largest image, so a first install and each upgrade download less.

### A Bot can send, draft and reply in Gmail

OpenBot left out every Composio action that takes a file, because a Bot has no way to supply one.
That also left out actions where the file is optional, such as an email's attachment, so Gmail's
send, draft, reply and update-draft actions never appeared and a Bot could read mail but not send
it. These actions are now offered without the optional file, and a call that includes one anyway is
refused with a message saying to try again without it. An action that cannot run without a file,
such as uploading one to Google Drive, is still left out. For an app that is already on, press
Refresh tools on its page in Admin to list the new actions, then grant them to a Bot as usual.

### Connect works for an app Composio already holds your account for

Pressing Connect on a Composio app, from a conversation's Connect card or from Connections, could end
in a refusal saying Composio already held a connected account for the app and that disconnecting it
would clear the way. The app showed as not connected, so there was nothing to disconnect. This
happened when Composio held the account and OpenBot had no record of it: on a fresh or upgraded
install, or on a second local install signing in as the same person with the same Composio key. Connect
now asks Composio again, records the account it holds, and shows the app as connected, the same way
opening the app's page already did. A Shared app's team account is still recorded only by an admin.
If Composio then reports no account after all, Connect says nothing was connected and asks you to
press it again. It no longer tells you to disconnect anything.

### A Bot with an app or web research can use its browser in a conversation again

A Bot that held any app or research tool, such as Parallel Search, could not open a page, click or
type in a conversation: every browser and computer step came back as unavailable, and the Bot
fetched the page some other way instead. Its browser now works beside those tools, as it does for a
Bot that holds none. Routines and other unattended turns are unchanged.

### An app a Bot could not use asks to be connected once

When a Bot reached for an app the person had not connected, such as Airtable, the conversation drew
the Connect card twice, and still did after a reload. The built-in LangGraph Bot now names the message
its tool calls belong to the way the conversation store does, so a conversation no longer keeps a
second copy of every tool call, and a conversation that already has one draws each call once.

### An app's steps are named for the app, never for the service behind it

A conversation named a Composio app's work after the broker and the vendor's own prefix: "Used
Composio Airtable", then "Airtable list bases". It now says "Used Airtable", and each step reads as
the action, "List bases", with the app beside it. An Arcade app is named the same way, as the app
rather than `arcade-Gmail`.

### An app a Bot cannot use yet asks once per turn

When a Bot's call to an unconnected app was refused, the Bot often also asked to show that app's
card, and the conversation drew the same Connect card twice. Each app's card is now drawn once per
turn; asking again in a new message can draw it again.

### The Computer panel shows the Bot's screen when it opens

Opening the Computer panel beside a conversation could leave it on "Waiting for the Bot's screen…"
while the Bot browsed, because the panel slid in from off-screen and the screen counted as out of
view for as long as it stayed open. The panel now starts showing the screen once it has opened.

### Plainer words, and one word for each thing

OpenBot now says **Bot** everywhere a person reads it, where screens used to mix Bot, agent, coworker
and assistant; "agent" is kept only for an outside program you connect. It says **admin** rather
than administrator, **conversation** rather than channel, and **OpenBot** rather than "this
deployment" on pages anybody can open. Headings, descriptions, empty states, errors and the
messages the server shows are shorter and say what happened and what to do next, across the home
page, a Bot's pages, Capabilities, Connections, Settings, conversations and Admin. Admin keeps the
exact setting names an admin needs, such as `COMPOSIO_API_KEY`. Text written for the model, such
as tool descriptions and instructions, is unchanged.

### Every settings screen is the same, slightly wider column

Settings, Admin, Connections, Capabilities and each Bot's pages share one column width, now 720px instead of 630px, so
no screen is wider than another and a row has room for its label beside its control. Sentences keep
their comfortable reading width inside it. The audit log stays wider, because it is a table.

### Capabilities and Connections sit beside Bots in the sidebar

The sidebar's Skills entry becomes two, below Bots: **Capabilities** (`/capabilities`), with Skills
(`/capabilities/skills`) and Memory (`/capabilities/memory`) as tabs under its title, Memory leaving
Settings; and **Connections** (`/connections`), the apps your Bots use as you, which leaves Settings
too. On the home page, Explore agents shows each Bot as a white card with its avatar on top, the same
card as elsewhere. The old
addresses — `/skills`, `/settings/connected-accounts` with any account beneath it, and
`/settings/memory` — redirect to the new ones, keeping `?connected=`, `?linked=` and a skill being
written or edited, so a consent begun before upgrading still lands on its page. OAuth, GitHub linking
and the Slack link confirmation now send people to `/connections`.

Connections is one searchable list. Apps you connect, apps on your organisation's account (marked
"Team account") and your GitHub and Slack links are rows of the same kind, with those already in use
first, and each opens its own page. GitHub's page holds your link, the repositories whose events can
start a responsibility (formerly "GitHub events"), and a way to a Composio GitHub app where one is
enabled, so GitHub is listed once; linking GitHub now comes back to that page. The reset for what
you let shared Bots use moves to Settings → Approvals, as **Shared Bots**.

### Each app on a Bot says whether you can use it, and you can ask an administrator for the rest

A Bot's page now says, for every work app the Bot holds, what that app is for the person looking:
ready, not connected yet, needing reconnecting, waiting on your organisation's shared account or on
an administrator's approval of who the Bot reaches, not switched on or not finished setting up, or not
given to this Bot. On somebody else's Team Bot it says whose account the app runs on: the owner's,
which only the owner can reconnect, or your own, which the Bot asks to use the first time. Each comes with the one thing you can do about it —
Connect or Reconnect your own account, or Request access where only an administrator can help — and
apps are named by their own name ("Gmail", not "Composio Gmail"). In a conversation, a Bot that needs
an app it cannot use now puts the same card in front of you instead of a sentence: an account you have
not connected, a Shared app with no team account, an account the vendor no longer holds, and — through
a new `show_app_access` tool every Bot holds — an app that is switched off or not granted to it. The
card reads the app's current state when it is drawn, so it never offers a step already taken.
Administrators see waiting requests at the top of Plugins, a count on each app's row, and a Requests
section on the app's own page, where Approve switches the app on and grants the Bot the app's
read-only actions in one press (or says what has to be done first; other actions are chosen on the
Bot's page for the app) and Dismiss closes the request. Requests name who asked; nobody's connection
status is shown to administrators. A person may have 20 requests waiting at once.

A connection the vendor turns out to have lost now reads as lost everywhere once a call finds out: a
Composio account the vendor no longer holds is removed so it can be connected again, and a Google
Drive or Notion connection whose refresh token the vendor refuses is marked withdrawn, with Reconnect
on the card instead of a tool error. A Memory source that fails for the same reasons says so in words
rather than showing the card's marker.

On a deployment with no `COMPOSIO_API_KEY`, Settings → Connected accounts no longer lists Composio
apps, which nobody could connect there. An app's own page, reached from an older link, says it is not
available yet and that an administrator has to finish setting it up, instead of naming the setting.
The administrator's page for the app still names `COMPOSIO_API_KEY`.

### A new desktop install of v0.2.0 gets past Install again

A desktop app built from `main` stopped every new install at "Installing OpenBot" with
`shared/package.json: No such file or directory`. It had started reading `shared`, `toolkit` and
`extension` as packages, which v0.2.0 does not have: there `shared` is plain source and there is no
`toolkit` or `extension`. It now reads them only when the release includes them.

### A built-in Bot behind an OpenAI proxy answers again

A built-in Bot behind a gateway or proxy in front of OpenAI (an `OPENAI_BASE_URL` that is not OpenAI or
Azure) answers again on `gpt-5.6-terra` and on every other model that takes tools only through the
Responses API (`gpt-5.6` and later, the `-pro` models, `gpt-5.3-codex`, also under a gateway's `openai/`
name). OpenBot now sets `COPILOTKIT_OPENAI_API=responses` for those at boot, where CopilotKit 1.79.1 had
sent them to Chat Completions and every turn failed with "Function tools with reasoning_effort are not
supported". Every other model still uses Chat Completions there, and a value you set yourself still wins.

### Teach a Bot by doing the task in your own browser: the OpenBot Recorder

The OpenBot Recorder is a Chrome and Edge extension. A person names the task, does it in their own
browser, and the Recorder sends what they did, step by step (each click, entry, choice, submit,
Enter and page change, with what an agent needs to find that element again, and the one request a
step sent when it saved something), masked in the browser first, straight to Intelligence as a
trajectory in that person's own Learning space; the page's own traffic is never recorded, except the
agent's AG-UI events (below). Every Bot
they use then gets the Skills learned there, beside the Bot's own. OpenBot connects the browser and
hands out each capture pass; it receives nothing that is recorded.

- **The agent's side too.** On a page whose agent speaks AG-UI (over SSE or the Intelligence
  WebSocket, OpenBot's own chat included), the Recorder also sends the agent's side, in exactly the
  shape the CopilotKit SDK emits so Intelligence cannot tell the two apart: `agent.run`,
  `agent.message` (the person's own messages too), `tool.call` and `thread.linked`, a click inside a
  chat message with its Thread and message, and `agent.event` for what those leave out (a tool
  call's arguments and result, state, reasoning, errors), never one row per streamed token.
  CopilotKit's suggestion runs are left out, as its own capture leaves them out.
- **Clicks and typing come from CopilotKit main's own capture code**, carried as a Bun patch over
  `@copilotkit/learning` 0.0.1 (`patches/`, which the images and OpenBot Desktop copy) until main is
  published.
- **Settings → Browsers** connects the Recorder in this browser and lists every browser connected
  as you, each with a Disconnect. OpenBot Desktop can connect the Recorder on its own computer too.
- **Only a connected browser gets a capture pass.** The runtime's `trajectory/<id>/connect` route
  answers only the Recorder's own bearer, and binds the trajectory to that person; no Bot is
  picked or named. A signed-in session alone gets no pass, and the Recorder's bearer cannot run a
  Bot or read a conversation.
- **One Learning space per person.** Every recording joins the person's own Intelligence Learning
  container, `user-` and 32 hex digits derived from their OpenBot user id. OpenBot makes it when
  the browser connects (and again on a capture pass if it is still missing) with the same
  credential that makes the `openbot` container: a service token on a CopilotKit local evaluation
  install, or a CopilotKit CLI login against managed Intelligence. Intelligence's runtime key
  cannot make one. With neither, a missing space cannot be made, and the Recorder's popup says
  Learning will not see the recording; the recording still goes to Intelligence.
- **Every Bot a person uses draws on their space.** A run gets the Bot's own learned Skills, then
  the person's own, then any another person opened (below). On a name clash the Bot's own wins,
  then the person's own; two people's opened Skills with one name are both kept, each named
  `<their space>/<name>`. A person's space that is missing or unreachable never fails a run: it
  goes on with the Skills it has. Admin → Automatic Learning off, or a Bot excluded there, still
  means no learned Skills at all.
- **Settings → Learning** chooses who else's Bots use a person's Skills: only their own (the
  default), every Bot in the deployment, or the Skills they open one by one, and only Skills in
  their own space can be opened. Opening Skills to others needs **Admin → Enterprise controls →
  Skill sharing**, off by default: while it is off nobody can open their Skills, runs offer nobody
  another person's, and each person's choice is kept for when it is turned on. Runs read what is
  open from memory, refreshed at once on the replica that saved a change and within 30 seconds on
  the others.
- **What the Recorder collects is said before the first Connect** (Settings → Browsers, the
  Recorder's setup page, the Browser page and its Record form): your steps, what each step saves
  (the request and its answer), the conversation with an AG-UI agent on the page (your own messages
  too) and your narration, masked in your browser first.
- **Narration is off until you choose it**, asked before your first recording and remembered, and it
  is transcribed on your own computer only (Chrome's on-device speech recognition, with the language
  downloaded once on your click); where on-device recognition is not available, narration stays off
  and the page says why.
- **Every recorded tab shows that it is being recorded**, from its first step (a page cannot hide the mark: it
  comes back at once if removed or hidden), with one click to leave
  that site out of recordings; a left-out site records nothing, and the Recorder's options list the
  sites left out. A page you have only looked at is held while you stay on its site, and sent when you
  act there, move to another tab or stop, so leaving a site out at any point in a visit sends nothing
  of it.
- **A Recorder's connection ends** whenever your sign-in ends (signing out, signing out everywhere, an
  admin removing you or requiring SSO, your organization ending its session), or after it goes unused for
  as long as an OpenBot sign-in lasts; signing out does not finish, and says so, if they cannot be ended; a recording kept for a person who never connects again is deleted unsent
  after 7 days. A page on your own computer is trusted to connect without a click only at OpenBot
  Desktop's own address, as its native host confirms it, and connecting to another OpenBot or as
  another person always asks you first, saying which connection it replaces.
- **Intelligence must allow trajectories:** the `trajectories` licence feature,
  `FF_LEARNING_TRAJECTORIES=true`, a realtime gateway that can ask Intelligence whether an
  organization may capture, and an `INTELLIGENCE_GATEWAY_WS_URL` that people's browsers can reach.
- **`OPENBOT_RECORDER_EXTRA_EXTENSION_IDS`** lists other extension ids to trust besides the
  Recorder's own, for a fork or a build signed with another key. Each must be 32 letters from a to
  p, comma separated; **a value that is not stops the server at boot.**
- Connecting, disconnecting and refusals are audited as `recorder.connected`, `recorder.revoked`,
  `recorder.connect_refused`, `recorder.bearer_refused` and `recorder.trajectory_refused`; changing
  Settings → Learning as `learning.sharing_changed`, `learning.skill_opened` and
  `learning.skill_closed`.

### When OpenBot is open in Chrome or Edge, the Browser button uses that browser

With the OpenBot Recorder in that browser, one click on Browser opens Record and Stop right in OpenBot,
and the red dot follows the recording at once. If the Recorder is not connected yet, the same click
connects it (OpenBot Desktop and your organization's own OpenBot, when its address is set by policy,
need no Connect click; any other site still asks you to confirm). If it is not installed, the click
opens its store page in a new tab. Only the OpenBot the Recorder is connected to can start, stop or see
its recordings; any other website is told it is not connected. Settings, Browsers shows Connected
straight away when no Connect click is needed. OpenBot Desktop's own window, Safari and Firefox are
unchanged.

### Your own everyday Chrome or Edge, with the Recorder in it

On OpenBot Desktop the Browser button now works with your own everyday Chrome or Edge: your profile,
extensions, password manager and logins, not a separate copy.

- **Once the OpenBot Recorder is published** on the Chrome Web Store and Edge Add-ons, OpenBot Desktop
  registers it with your Chrome and Edge, and the browser installs it from the store and asks you once to
  turn it on (on a Mac the next time you restart the browser, on Windows while it runs, on Linux in Edge
  only). Before it is there, the Browser button opens the Recorder's store page in your Chrome (or Edge)
  so you can add it at once. Until the Recorder is published, the Browser button opens the OpenBot browser
  as before. Uninstalling Desktop on Windows takes the registration back out.
- **The Recorder connects through OpenBot Desktop as it installs, with nothing to click.** "Connect with
  OpenBot Desktop" in the Recorder's popup also connects at once; connecting from a web page still asks
  you to confirm. Once it is connected, the Browser button brings that browser to the front.
- **The red dot follows a recording in any of your browsers**, your everyday one included, on Desktop and
  hosted: the Recorder tells OpenBot when it starts and stops recording, and every 30 seconds while it
  records, and the dot goes out 90 seconds after a browser stops reporting.
- **The Recorder says what it collects** first on its setup page (above its request for your microphone)
  and on its Record form, before anything is recorded: every step in every tab you use until you stop, what is on those pages, your clicks and
  typing (secrets masked in your browser first), what each step saves and what you say, all going
  straight from your browser to your organization's own Intelligence, with a pass from your
  organization's OpenBot, which is told that you are recording, the task's name, when it started and
  how many steps it holds; when you record in a browser shown inside OpenBot, your narration passes
  through it to the Recorder without being stored.
- Migration `0067_recorder_activity` adds two nullable columns to `recorder_connections` (each
  Recorder's latest activity). Nothing existing changes.

### A recording follows every tab you use

While a recording runs, the OpenBot Recorder now records in every tab you use: any tab you switch to or
open, in any window, in the OpenBot browser and in your everyday Chrome. Before, it recorded only the
tab you started in and tabs opened from it, so steps in a tab you switched to were lost. Tabs you do
not visit during a recording are never recorded, and nothing on the browser's own pages (a new tab,
settings) or the Recorder's own is. A tab that reloaded as you switched to it no longer loses the saves
it sends.

### Record a task in a Bot's own browser, with nothing to install

A Bot's screen, opened larger from a conversation, is now a browser a person can work in: tabs, an
address bar, back, forward and reload sit above the page. Take control and the bar is yours (typing an
address, switching, opening and closing tabs, all from the keyboard too); while the Bot has control it
shows where the Bot is, read only. The OpenBot Recorder is already in every Bot's browser, idle until
someone records, so recording a task needs no extension and no Connect step.

- **Record replaces "Teach a browser workflow".** Name the task, press Record, do it, press Stop. The
  panel shows the name, the time and the step count, asks about narration before your first recording
  (the same choice as the Browser page), and after Stop says what was saved to your Learning space. The
  recording lands in Intelligence exactly as the Recorder sends from any browser, in your own Learning
  space, so every Bot you use learns from it, this one included.
- **Only you are recorded, never the Bot.** Record works only while you hold control, and handing it
  back (or the Bot's request ending) stops the recording, with its last steps sent before the Recorder
  disconnects; the Bot acts again only once the recording has ended. Taking control now records who
  took it, so on a shared Bot only that person can use the bar or record, someone else's recording
  shows only that one is running, and nobody else sees its name, its step count or its microphone.
- **Record runs on your own computer, never the one everyone shares.** Where every person's Bots run
  on one computer (Helm's shared mode, or `AGENT_COMPUTER_URL` with no supervisor), Record is refused
  in every Bot's browser and the panel says why: your Recorder connection would sit in the Bot's
  profile, where another person's Bot could read it. The bar still works. The computer refuses it too.
  With a supervisor (laptop, Desktop) or a Sandbox, a Bot's browser is on your own computer, beside
  only your own Bots, or on an isolated Bot's computer of its own, and Record works there. Your
  hand-back ends only your own recording: another person recording in the same Bot's browser on their
  own computer is never touched.
- **One connection per recording.** Record mints a Recorder connection for the person who pressed it
  and Stop revokes it; Settings, Browsers lists it as "<Bot>'s browser" while it lives, and says
  "recording now" for any browser that is recording.
- While a recording runs in a Bot's browser, that Bot's network policy also lets the Recorder reach
  OpenBot and the Intelligence gateway, on their own ports only; the Bot's own policy returns when it
  ends.
- **Removed: the old "Teach a browser workflow" panel and everything behind it** (its routes under
  `/api/demonstrations`, its instant skill draft, "Save and use with this Bot" and "Run on a schedule").
  Skills already saved from it stay, as ordinary skills; its recordings stay in the database, unread.
- When you take control yourself, the line under the screen no longer repeats your own request back as
  if you had said it.
- **What you type while you hold control stays yours.** After you hand back, the Bot reads a field you
  filled as "filled in by the person", never its value, in its page snapshot, its page text and its
  screenshots; a field you only tabbed through keeps the Bot's own value.
- **A Bot's request for help shows in the conversation**, with its reason and Take control, and folds
  into one line once answered. After you hand back, the Bot is told what you did and carries on, saying
  what it does next; if it still stops without a word, the card says so and offers Carry on.
- **Clear browser data.** One button beside reload, in a Bot's browser and in your own, asks "Clear this
  browser?" and wipes it: cookies, saved passwords, history, site storage and the screenshots kept of its
  pages. It starts fresh, signed out of everything; OpenBot's own Passwords stay. A Bot's browser can be
  cleared only by the person holding its control. Audited as `computer.browser_cleared`.
- Leaving a conversation while you hold a Bot's control no longer leaves it blank: the Bot's reply after
  you hand back shows when you return, with no "A browser task is paused" notice.

### Your own browser, opened from OpenBot, with the Recorder already in it

Wherever OpenBot can run a browser for you, the sidebar has a **Browser** button below Connections. It
opens your own browser with the OpenBot Recorder already in it and connected as you: no install and no
Connect step. On OpenBot Desktop one click opens your browser window, or brings it to the front, and
you stay where you are in OpenBot; record with the Recorder's button in that window's toolbar. On
hosted OpenBot the click takes you to the browser in the page. While a recording runs, the Browser
button shows a red dot; hover it for the recording's name and how long it has run. Name a task and press Record; the page shows the recording's name, how long it has run and
how many actions it holds, and after Stop it says what was saved to your Learning space (for example
"7 actions and 1 narrated phrase"), or that nothing was recorded, and says the same after a reload. Nothing a Bot does is recorded. When
your browser cannot open because of how OpenBot is set up, OpenBot tells you to ask an admin (on
single-user OpenBot, such as OpenBot Desktop, to quit and reopen OpenBot), the message stays until you
close it, and the reason is in the server's and the computer's logs.

- **On OpenBot Desktop** it is your installed Google Chrome, or Microsoft Edge where Chrome is missing,
  in a separate OpenBot profile, as its own window; opening it again brings that window to the front.
  OpenBot starts it itself rather than through Playwright, so tabs behind the one in front behave as
  background tabs, and OpenBot follows the tab you are on. It is an everyday browser: install your password manager from the Chrome Web Store (a password manager's
  link to its desktop app works, such as 1Password's), or sign in to Chrome and sync brings your
  extensions, bookmarks and passwords; saved passwords use the system keychain. Once you turn narration
  on, the Recorder hears your microphone itself, and the page shows whether it is listening, muted or
  cannot hear.
  Desktop runs this browser as a fourth process beside the server, app and worker, only where Chrome or
  Edge is installed. Installation copies the Recorder, prebuilt, out of the release's computer image into
  your OpenBot folder, existing installations download their OpenBot files once more after updating, and Stop
  and Quit let the browser close cleanly first. Chrome's extensions page lists the Recorder as an
  extension it cannot verify, because it is not installed from the Chrome Web Store.
- **On hosted OpenBot** the browser is the computer's Chromium, shown in the page with tabs, an address
  bar, back, forward and reload, and you click and type in it straight away. Only the Recorder is
  allowed in it. It runs only on a computer of its own (each person's own, as the supervisor and the
  sandbox give one): where Bots share one computer, which can run commands, the Browser button is
  hidden and the Browser page says why. While you record with narration on, the page transcribes it
  with your own browser's on-device speech recognition (Firefox has none, and the page says so; the
  narration switch reads off whenever it cannot hear you), and each phrase is placed before the steps
  you took while saying it. It reaches the open web, and OpenBot and the Intelligence gateway on their own
  ports, never anything else inside the deployment.
- **Only you** can see or use your browser, admins included. It appears in Settings → Browsers as your
  OpenBot browser and can be disconnected there, which signs out the Recorder in it at once (a recording
  in progress stops and is kept, and goes to Intelligence when you next record). Each open replaces its
  previous connection, and Record after a Disconnect connects it again first.
- A person's hosted browser closes after going idle as a Bot's does, and the computer's browser cap
  closes the least recently used first; OpenBot Desktop's own window is never closed for being idle.
- On Linux, OpenBot Desktop also finds Chrome and Edge on the `PATH` (Flatpak builds cannot hold the
  Recorder and are not used), and the Browser page says why when there is none. On Windows, Stop and
  Quit ask the browser to close before ending it. Uninstalling on Windows, and removing the Linux
  package, deletes the OpenBot browser's profile and the Recorder's files.
- `OPENBOT_RECORDER_DIR` on a computer is the built Recorder it puts in a person's browser; the computer
  image sets it, and without it the computer still serves Bots and refuses to open a person's browser,
  saying why. `OPENBOT_BROWSER_URL` on the server runs people's browsers on a separate computer
  (OpenBot Desktop sets it). The local Chrome helper (`scripts/start-local-chrome-computer.ts`) now also
  starts when only Edge is installed.
- A computer's network rules can allow a site by name on given ports only (`ports` on a domain rule).
- **Each browser on a shared computer follows its own network policy.** Browsers there now identify
  themselves to the computer's network filter, so a Bot allowed to reach a service is no longer refused
  because another browser on that computer is not, and no browser borrows another's allowances.
- A hosted person's browser says who it is as a hosted Bot's does (no `HeadlessChrome`), but never
  carries the deployment's Web Bot Auth signature: a person browsing is not the deployment's Bot.
- A person's browser always runs the Recorder that came with its OpenBot, even in a profile that ran an
  earlier one, and keeps it pinned to the toolbar once.
- A Recorder that is slow to answer is refused instead of taking down the computer and every browser
  on it. Typing on a live screen reaches the page in the order typed.
- Opening the Browser page twice in quick succession (reloading it while your browser is still
  opening, for one) opens your browser once, connected; before, both opens could be refused, most
  often the first after the Recorder was updated. When a browser cannot be opened, the server's and
  the computer's logs say why and at which step.
- **Google loads in Bots' browsers again.** Behind the computer's network filter, Google's pages never
  finished loading (Chromium restarts the request for client hints and the restart was lost); the
  computer now launches every filtered browser with that restart switched off.
- When a page does not open, OpenBot names the site and says it did not load or was refused, instead of
  showing a browser error, the address bar keeps the address that failed, and a slow page says it is
  slow rather than that the browser could not be reached.
- A package can no longer give a Bot an id shaped like `person-` and 32 hex digits.
- The Recorder times a narrated phrase from its first word when Chrome reuses a result slot; it was
  stamped up to seconds early.

### The desktop window answers while software is installing

Clicking or focusing the desktop window while it downloaded local software showed a spinning cursor
until the download finished. The window now comes forward at once and keeps the setup screen.

### A reinstall no longer picks up the previous installation's Bot files and sign-ins

A desktop installation set up again after its folder was deleted reused whatever the previous one
left in the container engine: Bot workspace files, and each Bot's browser profile with its website
sign-ins, under the same Bot ids. Only the database was checked. Start now finds every volume and
stopped container the previous installation left and offers Start fresh, which deletes exactly those
and then starts; nothing is reused without asking. To keep the data, restore the previous folder
instead. A container from it that is still running stops the deletion until it is stopped. An
installation with its saved key keeps its data as before.

### A new desktop install starts its server again

A desktop install of v0.2.0 stopped at start with `server stopped straight away (exit status: 1)` and
`Cannot find module '../../../agent-computer/src/egress'`. The server imports its egress rules from
`agent-computer`, and the desktop app did not copy that folder when it laid out the deployment. It
does now, and a test fails if the deployment's code imports anything the desktop app does not copy.
An install laid out by an earlier app is asked to finish installing when it starts; installing
downloads the same release again with the missing folder. Settings and data are kept.

### A new Bot is made from a sheet that asks where it runs first

New Bot opens a sheet instead of the four-screen wizard. It asks where the Bot will run, with Run it
here chosen; a framework you run asks for its address next, and Continue checks from the server that
something answers there before going on. The name, title, instructions and who can see it come
last. A Bot given only a name gets a title and instructions the server accepts: for one that runs
here, the instructions are a short prompt naming it. The frameworks list Claude Agent SDK, Google
ADK, Google Antigravity and LangGraph first; AG2, Agno and Langroid now show their marks, and every
mark sits on a light tile in dark mode.

### A run of tool calls folds into one line

Consecutive tool calls a Bot makes without drawing anything now collapse into one line ("Used 5
tools") that opens to show each, as connector calls already did. Calls that draw an interface, and
calls waiting on the person, still stand on their own.

### Onboarding says which pictures are pictures, and tells a local install more

The illustrations in onboarding sit in a muted frame and can no longer be clicked, tabbed into or
read out as controls. On a single-user install, three more slides follow: that its data stays on
the machine, which agents it can bring, and how to deploy it for an organization.
`/api/capabilities` gains `localEvaluation`, true in single-user mode.

### An HTML-only email reaches its trigger as the sender wrote it

An email trigger reads an HTML-only mail by stripping its tags, and the character references stayed:
the Bot read `AT&amp;T`, `we&#8217;re` and `Q3&nbsp;numbers`. Numeric references, `&amp;`, `&lt;`,
`&gt;`, `&quot;`, `&apos;` and `&nbsp;` are now decoded, once, so `&amp;lt;` reads as `&lt;`.

### An email in another charset reaches its trigger as the sender wrote it

A base64 or quoted-printable email part was always read as UTF-8, whatever charset its Content-Type
named, so an `iso-8859-1` mail reached the Bot with every accented letter turned into `�`. Each part
is now decoded in the charset it names, and a charset the runtime does not know still reads as UTF-8.

### The Bot's screen opens only when there is something to watch

Asking a Bot a question it answered in words could still open its computer beside the conversation,
on a still screen, for an action that never happened.

- **A call that never reaches the screen no longer opens it.** Reading, writing or listing a file,
  and running a command, happen on the computer rather than on its display. Only work that happens
  on the screen opens it.
- **A refused action takes its screen back.** The screen is announced before the action so a page
  can be watched while it loads; an action a policy, a capability switch or a network rule refuses
  never touches the browser, so the screen it opened closes again. A refusal does not close a screen
  some earlier action in the same run legitimately opened, and an action that was permitted and
  failed keeps its screen, because the page may have moved.
- **A Bot is no longer given computer tools this deployment would refuse.** Admin → Controls already
  decided whether anybody may use a Bot's browser (`Cloud browser use`), its files and shell
  (`Cloud computer use`) and the network (`Cloud network access`), and the boundary enforced all
  three — but the Bot was still offered the tools, so it reached for one, was refused, and spent the
  turn saying so. The tools a switch turns off are now withheld from the Bot in the first place.

### A repeated minute in a routine's schedule is described once

A schedule like `0,30,0 9 * * *` fires at 09:00 and 09:30, but the routines page and the model were
told "Every day at 09:00, 09:00 and 09:30". Repeated minutes are now said once, as repeated weekdays
already were.

### An app you have not connected is offered where you are reading

A Bot asked to use an app whose account the person had not connected answered with the name of a
screen somewhere else: "Connect it in Settings and ask again." The conversation now carries the
thing itself — a card naming the app, with a Connect button.

- Pressing Connect opens the vendor's consent in a **new tab**, so the conversation is not replaced
  by a page load and the question is still there afterwards. The card watches for the account to
  appear and says so only once the server lists it, never merely because somebody came back.
- It covers an account that was never connected, one disconnected while a call was in flight, and
  access that was withdrawn. An app shared across the deployment still says to ask an administrator,
  since the person reading cannot connect it.

### No-sign-in startup rejects addresses without a host

With `OPENBOT_SINGLE_USER=true`, an address such as `example.com:3010` in `OPENBOT_PUBLIC_URL`,
`OPENBOT_APP_URL` or `TRUSTED_ORIGINS` now refuses startup. It previously counted as a private
network address and only warned, even though the missing URL scheme left its host unidentified.

### A reply's tool calls fold into one line

A Bot that searched, read two pages and checked Drive before answering drew four lines above its
answer. Adjacent connector calls and browser steps now fold into one line that says what was done,
such as "Searched the web and read 2 pages", with an icon for each kind of step. It names the step in
progress while the Bot works, and counts issues when a step was blocked or failed. Opened, it lists
each step with its query, page or connector, and each step opens to what it was given and what came
back. A single connector call keeps its own line, and approvals, connection requests and anything the
app draws itself stay outside the fold.

### Public-web research works with Exa and Firecrawl, not only Parallel

Four new catalogue entries give a Bot public-web search and page reading without its browser:
**Exa Search** (free, rate-limited), **Exa Search (API key)**, **Firecrawl** (free) and **Firecrawl
(API key)**. They sit beside the two Parallel entries, and nothing is granted to any Bot until an administrator does it.
See [docs/web-research.md](docs/web-research.md).

- **The research guidance follows whichever provider a Bot holds.** It used to switch on only for
  Parallel's two tools. Now a Bot holding any provider's search and fetch tools is told how to use
  them, and a Bot holding more than one uses the one the person asks for.
- **A Bot holding a research provider searches without being asked** when an answer depends on facts
  that change, such as current figures, rankings or recent events, and stops after a search or two.
  Before, every Bot was told not to go looking, so one holding a search tool still answered from
  memory. A Bot with only its browser now says it can open pages but cannot search.
- **A conversation doesn't say which provider searched.** Research calls show as "Search the web"
  and "Read web pages" rather than "Web search exa", and the Bot doesn't name the provider unless
  asked. The Bot's access page still shows which provider it holds.
- **The shipped `research-public-web` skill declares roles, not Parallel.** Its tools are now
  `@research/search` and `@research/fetch`, which match the search and fetch tools of every research
  provider the Bot was granted. A skill written by a person can declare the same roles, and the
  Skills page offers them under "Public-web research". A role grants nothing.
- **Exa and Firecrawl list their reads.** Every other tool they advertise counts as a write, so a
  Firecrawl monitor deletion or an Exa agent run goes through the same policy as any write.
- **An API key can go in the vendor's own header.** Exa reads `x-api-key`; the deployment key for
  that entry is sent there. The admin page now says the key is "Sent with every call to this vendor"
  rather than calling it a bearer token.

### Bot turns hold their conversation more carefully

Routines, responsibilities, background research, wake-ups, group turns and Bot-to-Bot handoffs keep a
lock on the conversation while they run and renew it as they go.

- **A failed renewal no longer stops the turn.** Before, any failed renewal stopped a routine or
  responsibility turn, including a network blip. A stopped turn is retried from the start, so a Bot
  that had already sent an email could send it again. Now a turn stops when Intelligence says the
  conversation belongs to another run (409), or when renewals have failed for so long that the lock
  (120 seconds) would lapse before the next one, whatever the failures were. It stops while the lock
  is still its own. A shorter blip rides through.
- **A handoff that loses its lock now stops.** Before, a handoff ignored every failed renewal and
  kept writing, even into a person's own channel after they started typing there. Now it stops, gives
  the conversation back and is retried a minute later.
- **A paused Bot's handoff no longer locks the conversation.** A handoff now checks that the Bot is
  not paused, and that "Use Bots" and the model allowlist allow it, before taking the lock. Before,
  every retry took the lock briefly and could refuse the person's own message.
- **Routine turns ask for a 120-second lock.** This is the lifetime Intelligence already applies, so
  nothing changes on today's platform.

### A sign-in's verification code is asked for after the password

The private sign-in form used to ask for a username, a password and "a verification code, if the
site asks for one" all at once, so a person had to guess whether a code was coming and type one
before the site had sent it. Now the form asks only for the username and password. If the site,
once it has the password, shows a one-time-code field, the request waits in a new `code_required`
state and the form asks for the code the site just sent, on its own. A wrong code keeps asking; a
code nobody enters expires with the request, and the person can still take over the browser or
cancel. The Bot is told only how it ended, never the code, and a saved login still never stores one.
The step is audited as `computer.sign_in_code_requested`, and a failed code as
`computer.sign_in_failed` with `step: "code"`.

### A licence token from a store reaches the server

The Helm chart passed `COPILOTKIT_LICENSE_TOKEN` to the server only when `secrets.licenseToken` was
written as a literal. A token synced through `externalSecrets`, which the chart's own EKS example
does, reached the Secret and never the pod, so a self-hosted deployment ran unlicensed with nothing
saying why. It is now passed whenever `externalSecrets.data` names `license-token`, and as an optional
reference with `secrets.existingSecret`, where the chart cannot see the Secret's keys. The chart's
CI check now also fails a render in which a store syncs a key that nothing reads.

### OpenBot says at boot when Intelligence will refuse memory

A self-hosted Intelligence needs its own licence. Without one it answers every runtime entitlement
read with `RUNTIME_ENTITLEMENTS_SELF_HOSTED_MISCONFIGURED` and refuses memory, while conversations
carry on and nothing in OpenBot's log says why. The server now asks once at start-up and logs
`intelligence-entitlement-not-ready` with the code and where the licence goes, and
`intelligence-entitlement-unreadable` when Intelligence cannot be asked. Start-up does not wait for
the answer.

### The server says at boot when its key cannot call the configured model

A key without access to the tenant package's `default_model` passed every start-up check and failed at
the first message, as "The model … does not exist or you do not have access to it", in front of
whoever sent it. The server now asks the provider once at start-up and logs `model-unavailable` with
the model and the fix, or `model-credential-rejected` for a refused key. It asks only OpenAI and
Anthropic themselves, not an endpoint set by `OPENAI_BASE_URL` or `ANTHROPIC_BASE_URL`, says nothing
while no key is configured, and never delays start-up.

### The Helm chart pins by digest, mounts a tenant package, and takes a Composio key

Three things a deployment on Kubernetes did by hand now have values of their own:

- `image.digest` deploys exactly the image a release's `container-images.json` names, as
  `repository:tag@digest`. It refuses anything that is not `sha256:` and 64 hex characters.
- `config.extraVolumes` and `config.extraVolumeMounts` mount volumes on the server and on the routines
  and computer-culler CronJobs, the pods that load the configuration. A tenant package from a
  ConfigMap no longer needs a custom image.
- `secrets.composioApiKey`, or `composio-api-key` named in `externalSecrets.data`, reaches the server
  as `COMPOSIO_API_KEY`. Only the server receives it, not the CronJobs.

With none of them set, every target renders exactly as before.

### Fewer "Verify you are human" pages

Sites behind Cloudflare challenged a Bot's browser on sight, and opening one could restart the
computer and leave the person a blank page to solve. Now:
- The computer no longer restarts on such a page, and a help request reopens the page the Bot was
  on, so the person taking control always gets the check to solve. That handoff is the designed
  fallback for a check a Bot cannot pass.
- A hosted computer runs headed Chromium on its own virtual display, behind the same live screen.
  Headless Chromium is what bot checks catch first. A computer still run headless no longer calls
  itself `HeadlessChrome`.
- Web Bot Auth, off unless switched on: with `WEB_BOT_AUTH=on` (Helm: `config.webBotAuth: "on"`)
  and an https public URL, every request a Bot's browser sends is signed and the key is published at
  `/.well-known/http-message-signatures-directory`. Register the deployment once
  with Cloudflare (Bot Submission Form, Request Signature) for sites that allow signed agents to let
  Bots through. See docs/configuration.md. Every site a Bot visits sees the deployment's URL.
- A residential or ISP proxy is a first-class setting: `EGRESS_PROXY_DEFAULT`, or on Helm
  `computers.egressProxy` with the URL in a Secret. Off by default; turning it on makes Bots' traffic
  look like a person's home connection, which is the operator's choice to make.
- Bun 1.4.3 throughout, which fixes the connection crash behind the restarts.

### Memory sources and background research are on by default

A fresh deployment used to remember only what a person told a Bot: connected-app memory sources and
background research each waited for somebody to set them up, one Bot at a time. Now, when a person
talks to one of their Bots in a conversation with that Bot alone, OpenBot switches on background
research by that Bot (read-only as before, every four hours, first run one interval later). And from
any turn a Bot takes for a person, each app the person connected in their own account, that the Bot
can read, becomes a memory source for that Bot, except on a Team Bot somebody else published, where
the person's own accounts need their consent. Sources read as the person, their facts reach that Bot only, and imported facts wait for the
person's review before they go to Intelligence, exactly as a source made by hand. Shared apps and apps
that need no account are not added; a person still adds those by hand.

Turning either off keeps it off, and removing one is remembered: OpenBot never switches it back on,
and resetting the Bot keeps both. Nothing already saved changes. Set `OPENBOT_MEMORY_SOURCE_DEFAULTS=false` or
`OPENBOT_PROACTIVE_DEFAULTS=false` (Helm: `config.memory.sourceDefaults` / `researchDefaults`) to stop
new defaults for the whole deployment.

### Automatic Learning creates its container where OpenBot holds a credential that can

The runtime key cannot create Learning containers, so a deployment without the `openbot` container
collected nothing until somebody ran a helper. Now:
- `bun scripts/setup-learning.ts` (and `scripts/start.sh` on every start) creates it with a CopilotKit
  CLI login even when no project is selected in the checkout, choosing the runtime key's project.
- `INTELLIGENCE_SERVICE_TOKEN` with `INTELLIGENCE_PROJECT_ID` lets the server create it by itself, on a
  CopilotKit local evaluation install (the only kind where Intelligence accepts a service token for
  Learning).
- The Helm chart runs a setup Job when `config.learning.setup` names a CLI-login Secret or a service
  token Secret.
- Admin → Automatic Learning has a "Create the openbot container" button when the deployment holds one
  of those, and otherwise, like the server log, says exactly what to run.

### Automatic Learning assigns its container without a trip to Admin

Learning was on by default but collected nothing until somebody assigned a container. Now, when
nothing is saved under Admin → Automatic Learning and `CPK_INTELLIGENCE_LEARNING_CONTAINER_ID` is
not set, the server assigns its Intelligence project's `openbot` container as the default as soon as
that container exists, records it in the audit log, and the Admin page says so. A saved setting,
including off, is never changed. The runtime key cannot create a container, so
`bun scripts/setup-learning.ts` now creates `openbot` in an existing key's project instead of
refusing, and `scripts/start.sh` runs that check on every start without a browser or prompt. Set
`OPENBOT_LEARNING_AUTO_ASSIGN=false` (Helm: `config.learning.autoAssign: false`) to keep the old
behaviour.

### Memory lives in CopilotKit Intelligence

A deployment entitled to Intelligence memory now keeps its people's memories there: Intelligence holds
the content and ranks recall, and memories another app on the same project formed for a person appear
in their Memory page and reach their Bots. OpenBot still records each memory's provenance, review state
and which Bot or source it came from, and applies those rules to everything Intelligence returns, so a
Bot-formed memory still reaches only the Bot that formed it. Without Intelligence memory nothing changes:
OpenBot's own tables remain the store.

## 0.2.0

**Before upgrading.** Two things change for an existing deployment:
- Migration `0052_shared_brokered_accounts` copies every Composio connection into a new
  `brokered_connections` table and leaves `composio_connections` in place, unwritten. Rolling back to
  0.1.2 works, but accounts connected after the upgrade are invisible to it.
- A handoff now records what started the run it came from. Older remote Bots' signed runs carry no
  such record for up to ten minutes after the upgrade, and calls they make to a Shared app in that
  window are refused.

### The desktop asks before every command that can edit a folder

When a Bot runs a command in a folder shared from the desktop app, the person sees a prompt that can
offer "Always allow in this folder". That choice now covers commands that only read the folder. A
command that can change or delete files in it shows the prompt every time, without the "Always
allow" option. Folders already set to "Always allow" work as before for read-only commands.

### One Bots list, and one page per Bot

Agents, Team Bots and Bots were three lists of the same Bots. `/bots` is now the only one — pinned,
yours, shared with you, and the ones you hid — with **New Bot** at the top. A Bot's page holds
everything about it: its routines, its skills and what it may reach, who it is shared with, and its
name, role and connection. Where updates reach you and your answers to shared Bots moved to
Settings. `/agents` and `/team-bots` still work and open the new places. A Team Bot an administrator
assigns to a group is pinned at the top of its members' Bots list instead of sitting in their
sidebar.

The sidebar no longer lists each Bot that needs you. A badge on Bots counts the questions, approvals
and stalled hand-offs waiting across all of them, and Bots lists those Bots first, under Needs you.
Browser notifications when a Bot starts needing you are unchanged.

The sidebar is now Bots and Skills. Each Bot's page holds what that Bot is waiting on you for, its
suggested next steps, its responsibilities, where it reaches you, its memory sources and background
research, and its approval rules. `/approvals`, `/memory`, `/reachability` and `/responsibilities`
still work and open the new places. Messages from Bots, Slack and Teams that named those pages now
point at the Bot's page.

A group conversation is started like any other: put two or more Bots in the To: field of a new
conversation, in the order they should answer. The separate group button and `/group/new` screen
are gone; `/group/new` opens the new-conversation screen.

Settings now also holds whether your Bots ask before acting, rules for every Bot, your memories, your
devices and recent deliveries, and GitHub event sources. Team approval settings and shared account
requests moved to Admin → Approvals.

### People can link their Slack and GitHub accounts

Settings → Connected accounts gains a Linked accounts section with one card per account a person can
link. Slack links through a one-time code sent to the OpenTag app in a direct message; a code posted
in a channel is cancelled. GitHub links through a GitHub App's user sign-in, set with
`GITHUB_APP_CLIENT_ID` and `GITHUB_APP_CLIENT_SECRET` (both or neither); the server refuses to start
with them and no public URL. Nothing reads the links yet: they are what GitHub alerts and reviews will
build on. Migration `0053_identity_links` only adds tables.

### A credential written as the word after a flag is redacted

`docker login -p secret`, `sshpass -p secret` and `redis-cli -a secret` were recorded with the
password in clear: the rules recognised a flag whose name says what it carries, and mysql's attached
`-psecret`, but not a credential passed as the word after the flag. `redis-cli -ahunter2` was worse —
the attached form reads as a flag called `-asecret`, so the rule for a flag named after a secret
redacted the word *after* it and left the password. A URL with no user, `redis://:secret@host`, was
missed the same way, and so were curl's proxy credentials in `--proxy-user` where `-u` and `--user`
were covered. All of them are now redacted, in the command kept for Action Recording and in the copy
exported to a telemetry collector. A password separated from `-p` by a space is left alone: mysql
asks for it at the prompt and the word after the flag is the database name. Each of these rules ends where its
command does, so the port in `sshpass -p secret ssh -p 2222`, or in a `docker run -p 8080:80` on the
line after a `docker login`, is left alone.

### An app's account can belong to the team

An administrator can make a Composio app Shared: one account, connected once, that every Bot granted
the app acts as. Who may use it through each Bot is approved per Bot — owner only, named people and
groups, or everyone, and separately whether email, Slack or webhook input may — and checked on every
call. Requests to widen it wait in the Approvals inbox. Writes through a Shared app ask the person
first.

### A new deployment starts with two coworkers, not twelve

The example package loaded every coworker in `examples/fintech/agents/`, so a fresh deployment opened
with General Assistant, Knowledge and ten more at once. The ten now live in `examples/fintech/catalog/`,
which is not loaded, and a new deployment starts with General Assistant and Knowledge. Risk Analyst
and the picked harness still register when their endpoints are configured. To keep any of the ten,
copy its file from `catalog/` into `agents/`.

A deployment that already registered them keeps them. A coworker dropped from the package is not
retired on the next boot: its row stays, still listed and still refused by delete as protected,
because only a remote coworker with a blank endpoint is retired automatically. To remove the ten
from such a deployment, set `deleted_at` on their `agent_profiles` rows after upgrading (see
[configuration.md](docs/configuration.md#agents)).

## 0.1.2

### CopilotKit 1.77 and AG-UI 1.0

OpenBot now runs on CopilotKit 1.77.0 (`@copilotkit/runtime`, `react-core` and `a2ui-renderer`,
from 1.73.1), which carries the Intelligence client, and on AG-UI 1.0 (`@ag-ui/core` and
`@ag-ui/client` 1.0.1, from 0.0.59). A managed Intelligence project needs nothing changed; it is the
client in the server that moved. Among what comes with it: thread naming falls back to the first
message, the realtime connection keeps its place across a repeated checkpoint, an interrupt resume
gets a run id of its own, and generated A2UI controls no longer submit the page's own forms.

Bots served from their own endpoint keep working as they are. AG-UI 1.0 still accepts the earlier
event shapes, so `agent-bot`, `agent-langgraph` and the Python Bots were not changed.

A tool result's `error` field is gone from the `TOOL_CALL_RESULT` event, because AG-UI 1.0 does not
define one. The refusal is still in the result's text and on the tool message, which is where a
Bot's next turn reads it.

## 0.1.1

- A password given to `curl` as `-uuser:password`, `--user=user:password` or `-u "user:pass word"` is
  now redacted in a Bot's recorded shell command. Only `-u user:password` with a space and no quotes
  was recognised, so the other spellings kept the password in the command that was stored or exported.
- A password, token or API key sent as a JSON field in a shell command is now redacted before the
  command is kept or exported. `curl -d '{"password":"x"}'` was recorded with the secret in clear,
  because only `NAME=value` and `--name value` forms were recognised and a quoted JSON key was
  neither. The key is still shown, so the command reads the same.

- A Bot's browser is now refused names under `.localhost`, such as `http://admin.localhost:5432`, the
  same as bare `localhost`. The whole `.localhost` zone is loopback and Chromium resolves it without
  DNS, but only the exact name `localhost` was on the refused list, so a deployment that had not opted
  into private hosts could still be pointed at its own services this way.

- `OPENBOT_SINGLE_USER` is now refused with a public name that starts with `127.`, such as
  `https://127.example.com` or `https://127.0.0.1.nip.io`. The check for a loopback address matched
  any host beginning `127.`, so a public address like that read as this machine and the no-sign-in
  administrator was allowed on it. Only a full 127.x.x.x address counts as loopback now.
- A cancellation the native host never collected is now dropped instead of being reported as
  pending forever. Every timed-out, stopped or revoked host operation queues a cancel for the desktop
  worker, and only that worker ever removed it: a worker that stopped polling left the entry in
  memory for the life of the process, so the Host access panel showed an operation that could never
  finish. A desktop that reconnects within the operation timeout is still told to stop.
- A Bot's shell now honours a Stop that landed before the command was spawned, not only one that
  arrives afterwards. A person who pressed Stop in the window between the request reaching the
  computer and the command starting got no answer until that command finished on its own.
- A file download refused because the computer's response carried no usable byte length now releases
  the connection before reporting the refusal. The unread body could be as large as the whole
  download budget, so a computer reached through a proxy that re-chunks left a transfer running and a
  connection checked out of the pool on every attempt.



- A conversation title cut at 60 characters no longer ends in half an emoji. `slice` counts UTF-16
  code units and an emoji is two of them, so a title cut between the halves rendered a replacement
  character in the sidebar and the picker, where the character itself should have been.

- A tool result that arrives before the call it answers is now paired with that call by the LangGraph
  Bot, as the sibling Bots already did. Read back from the durable thread store the result arrives
  first, which is a payload no provider accepts: a tool message with no preceding call, then a call
  with nothing following it. The model answers that with silence rather than an error, so the Bot
  stopped responding for the rest of the conversation.

- Pressing Stop now stops the computer even when the desktop worker never collects the instruction.
  A stop was queued with no timeout and the worker was the only thing that could ever remove it, so a
  worker that stopped polling left the entry in memory for the life of the process and the Host
  access panel showed an operation that could never finish, growing by one per press. Pressing Stop a
  second time also withdrew the first Stop before the desktop could collect it, and rejected a request
  that nobody was waiting for, which the server treats as fatal. A desktop that reconnects within the
  operation timeout is still told to stop.

### A computer refuses the cloud metadata address written through the NAT64 prefix

A Bot's computer is now refused the cloud metadata address when it is written through the NAT64
prefix (`64:ff9b::a9fe:a9fe` is 169.254.169.254), under every network policy including allow-all.
Only the plain and IPv4-mapped spellings were refused, so on a network with a NAT64 gateway the
metadata endpoint was one rewrite away. Browsing already refused this spelling; the computer's
filter now agrees.

### `?sslmode=require` on `DATABASE_URL` now connects to a managed database

A deployment pointed at RDS, Cloud SQL or Azure Database could not start. The server sent
`sslmode` to Postgres as a connection parameter instead of turning TLS on, so the connection went
out unencrypted and was refused with `no pg_hba.conf entry for host ... no encryption`, the very
error the Helm chart's README says `?sslmode=require` avoids. Migrations were unaffected, which is
why a deployment got as far as a migrated database and then crash-looped. `sslmode=require` now
encrypts the connection, and `sslmode=disable` turns TLS off. `sslmode=verify-full`, with an
optional `sslrootcert`, checks the certificate on Bun 1.4 and later and is refused on Bun 1.3,
which connects to any certificate. `verify-ca`, `prefer` and `allow` are refused with a message
naming the modes that work.

### A coworker the message speaks to is routed to without asking a model

Addressing a coworker by name went to the intent router like any other message, so the deployment
paid a model call to be told what the person had already said, and sometimes was told something
else. A message that speaks to a coworker by its full name now routes straight to them: it opens
with the name ("Risk Analyst, please check this"), names it with `@`, or asks it ("ask Risk Analyst
to review this"). It is recorded as `matched a coworker’s name in the message` with
`viaNameMatch: true` on the same `channel.routed` row. A name in passing ("don't send this to Risk
Analyst") and a word that only ends a name ("review this contract", "my meeting notes") still go
to the router. When the message addresses more than one coworker, or two share the addressed name,
it is refused with distinct labels, and the composer keeps the draft and asks the person to choose
instead of starting the default coworker. Explicit picker choices still use `viaMention: true`.

### A Bot's turn in a group is no longer offered coordination tools it cannot call

A Bot answering another Bot in a group conversation was offered `ask_person`, and `message_bot`
when hops allowed it, but every call was refused with "This run no longer has permission to
coordinate work in this conversation" and an `mcp.callback_refused` row nobody had caused. A run is
now offered these tools only when a call from it would be allowed, so that turn is offered neither.
A call that is refused anyway, from a schema offered earlier, is still refused and audited.

## 0.1.0

**Before upgrading.** Eight things change for an existing deployment:
- Automatic Learning is on unless an administrator saved it off. It does nothing until a Learning
  container is assigned; see below.
- A Bot's computer refuses the network until the server pushes its policy. A computer run without
  an API server can set `EGRESS_POLICY_REQUIRED=0` for the old behaviour.
- The upgrade runs migrations `0042_user_preferences`, `0043_plugin_logos`, `0044_voice_sessions`,
  `0045_channel_activity_source`, `0046_automatic_learning`, `0047_agent_pinning`,
  `0048_coworker_parity`, `0049_coworker_parity_lanes`, `0050_review_fixes` and
  `0051_routine_enabled_at`.
- An existing Windows clone checks text files out with LF only after
  `git rm -r --cached . && git reset --hard` on a clean tree.
- The signed-in app shows a bar offering CopilotKit's help self-hosting OpenBot, unless the
  deployment is on a paid Intelligence plan. Set `OPENBOT_SELF_HOST_BANNER=false` to remove it for
  everybody.
- An egress rule with a malformed IP range, such as `10.0.0.5/`, used to be read as `/0` and allow
  every IPv4 address. It is now refused, and a saved network policy that contains one is refused as
  a whole: the Bots under it fall back to an allowlist with nothing on it, so they reach nothing
  until the rule is corrected under Admin → Enterprise.

### A group reply the owner allows still reaches the Bot it names

A reply held until its owner allowed it to be shown in a group was written into the transcript and then stopped. The same reply allowed immediately was handed to the Bot it named. Allowing it now hands it on the same way.

**Before upgrading.** Four things change for an existing deployment:

### The app offers help self-hosting OpenBot, until you close it

A slim bar at the top of the signed-in app links to CopilotKit's engineers for help self-hosting
OpenBot. Closing it is saved to your preferences, so it stays closed on every device. A deployment
on a paid Intelligence plan (`pro`, `team`, `team_self_hosted` or `enterprise`, or a licence bought
through AWS Marketplace) never shows it; any other plan, or an entitlement that cannot be read,
shows it. A fork running OpenBot for its own organization hides it for everybody with
`OPENBOT_SELF_HOST_BANNER=false`.

### A request to the approvals API that is not JSON answers 400

A body that could not be parsed as JSON, sent to any approvals route that reads one, such as
`PATCH /api/approvals/preferences` or `POST /api/approvals/rules`, answered 500 with the parser's own
message. It now answers 400 "Supply a valid request.", as the delivery routes do.

### Syncing a memory source a policy refuses says why

When a connected app's policy refused the read behind a memory source's sync, `POST
/api/memory/sources/:id/sync` answered 503 "Memory is unavailable. Try again.", although the
refusal's own sentence was already saved on the source. It now answers 400 with that sentence, as
the plugin routes do for the same refusal.

### `@Ops Lead` in a group addresses Ops Lead, not Ops as well

In a group conversation, a reply naming `@Ops Lead` also addressed a Bot called Ops, because the
shorter name matched at the same `@`, so both answered. An email address addressed a Bot by its
domain: `jo@sam.com` reached a Bot called Sam. Where two names start at the same `@`, only the
longer one is now addressed, and an `@` straight after a letter or digit is not a mention.

### A webhook with many long top-level fields no longer stops the server

A trigger's event is cut to 32 KiB before it is recorded, keeping each top-level text field up to
1000 characters and an excerpt of the rest. A flat payload whose fields alone came to more than
that, such as forty 1000-character fields, left the excerpt nothing to give up, and the loop
trimming it never ended. That loop runs on the server's only thread, so every request stopped being
answered. The kept fields now get at most half the space, and the rest is still in the excerpt.

### A malformed IP range in an egress rule is refused instead of widening the rule

An egress `cidr` rule written `10.0.0.5/` was stored as `10.0.0.5/0`, which is every IPv4
address, so a typo for one host opened an allow-list to all of them. `/0x8` and `10.0.0.0/8/9` were
accepted the same way. A zone id such as `fe80::1%eth0` was accepted too, and then threw from the
filter on the first connection that policy judged. Each is now refused when the rule is saved, with
the sentence a malformed range already got. A rule like this saved earlier matches nothing.

### Deleting a channel twice is recorded once

A second `DELETE` of the same channel, from a retry or a second tab, still answers 204 as before.
It no longer tells every member again, and no longer writes another `channel.deleted` row to the
audit trail for a deletion that did not happen.

### A Bot's saved reply in a group is no longer replaced by a later error

In a group conversation, a Bot's reply was saved, then handed on: to Activity, to any consent
cards, and to the Bots it named. A fault in that hand-on, such as the audit trail being
unreachable, wrote the error's text over the saved reply and marked it failed, and a retry did not
bring the reply back. The reply now stays as saved, the fault is logged as
`group-turn-after-reply-error`, and any consent cards or handoff the fault interrupted are still
posted.

### The egress filter reaches an IPv6 upstream proxy and asks it for IPv6 hosts correctly

An upstream proxy configured at an IPv6 address, such as `http://[fd00::1]:3128`, could not be
reached: the filter handed the address to the socket with its brackets, and the socket looked it up
as a name. A `CONNECT` to an IPv6 host was also sent to the upstream without the brackets an
authority needs, as `CONNECT ::1:443`. Both now work.

### The Helm chart configures Slack, Teams, text messages, push, SCIM, inbound email and OpenTelemetry

These settings had no chart values and could only be passed through `config.extraEnv`. They now have
their own: `config.opentag`, `config.sms`, `config.push`, `config.deliveryPublicUrl`, `config.scim`,
`config.inboundEmail` and `config.otel`, with the OpenTag secret, the Twilio auth token, the Expo
access token, the SCIM bearer tokens and the OpenTelemetry headers under `secrets` (or an existing
Secret or store, by key). The install refuses what the server would refuse at boot, such as an
OpenTag secret under 32 characters or a partial set of Twilio settings. With none of them set, the
chart renders exactly as before, so a deployment already passing these through `config.extraEnv`
keeps working unchanged until it moves them across.

### A coworker at its own endpoint can hand work to another Bot

A grant letting a remote Bot (a coworker at its own endpoint) hand work to another Bot was accepted and stored, but the grant read kept only built-in Bots, so the remote Bot was never
offered `message_bot` and a call it made anyway was refused as not granted. The read now counts a
grant whatever the Bot's type, so a remote Bot hands work on through the same signed callback, grant
check, caps and audit rows as a built-in one, to a built-in Bot or to another remote Bot. The
coworker's handoff panel now offers it the same switches.

### A channel cursor with a malformed time reads as the first page, not a 500

`GET /api/channels` only checked that a cursor's time was a string before casting it with
`::timestamptz`, so a hand-edited or corrupted cursor such as `{"recency": "not-a-date"}` answered
500. A time that is not the UTC timestamp the list writes now reads as the first page, the way every
other malformed cursor already did.

### A playground component's Published switch publishes its source too

The Published switch on an admin component page called the generic publication endpoint for every
kind. For a browser-authored component that endpoint promoted the description and marked it
published without copying the playground draft, so Bots were offered a component the renderer could
not draw. Playground components now publish and withdraw both rows in one transaction; a missing or
empty description or HTML is refused instead of leaving a half-published component, and repeating
an unchanged publish no longer advances the revision.

### A proxy password containing `%` no longer stops every shell command

A proxy password with a `%` that does not start an escape, such as `p%zz`, made decoding it throw.
- In the computer's shell, which strips proxy credentials before every command, every `/exec`
  failed as a result.
- Resolving a Bot's egress proxy failed the same way.

Such a password is now taken as written, and it is still kept out of the shell's environment.

### Revoking a credential twice says so, instead of answering a server error

Revoking a credential that was already revoked, or that does not exist, now answers 404 with the
reason. Rotating one that is gone answers 404, and rotating one that is revoked or does not match
the key answers 409. Before, each answered a plain-text 500, as if the deployment were broken; a
double click on Revoke was enough to cause it. The refused-rotation audit row is written as before.

### The channel list no longer skips channels made in the same millisecond

The channel list's page cursor kept the last channel's time to the millisecond, while PostgreSQL
keeps it to the microsecond. Channels later in that same millisecond, as a package sync or an
import makes them, sorted after the cursor and were on no page. The cursor now carries the time to
the microsecond, as the audit trail's cursor already did.

### A package skill's slug has the same shape as one made in the app

The skills screen, the skills API and the store all accept a slug of 2 to 40 lowercase letters,
digits and hyphens that starts and ends with a letter or digit. `skills.yaml` accepted any length
and a trailing hyphen, so a package could seed `a`, `a-` or a sixty-character slug that nobody
could then edit. A package with such a slug is now refused at load, with a sentence naming it.
Every slug in `examples/fintech` already has the shape.

### A tenant package that repeats itself is refused by name, instead of failing at boot

Validation now refuses each of these, with a sentence naming the file and the repeated id:
- A skill named twice by one agent, or an agent listed twice in one channel's `permitted_agents`.
  Before, the server stopped at boot with a raw SQL error.
- An agent id repeated within `agents.yaml`, a channel id within `channels.yaml`, or a skill slug
  within `skills.yaml`. Before, the last entry silently won, though two files declaring the same
  agent were already refused.
- A remote agent left blank in `agents.yaml` but declared with an endpoint under `agents/` was
  dropped from every channel that named it. It is now treated as declared.

### `start.sh` and `stop.sh` see their own processes on Windows

In Git Bash on Windows, which has no `lsof`, `pgrep` or `pkill`, every process and port lookup in
the two scripts came back empty.
- `bash scripts/stop.sh` reported the app, the routine worker and the API server as not running,
  and left all three up.
- `start.sh` could not see a port held by another process.
- `start.sh` started another routine worker on every rerun, then reported that the one it had just
  started "did not stay up".

Where those tools are missing on Windows, the scripts now ask PowerShell, which ships with Windows.
Everywhere the tools exist they are used exactly as before.

### The supervisor and the Python Bots compare their tokens in constant time

The supervisor compared its bearer token with a plain string comparison, and the eleven Python Bots
compared the shared agent token as text, which answered 500 rather than 401 on a header carrying a
non-ASCII character. Both now compare bytes in constant time, as the server and the computer already
did. A wrong or missing token is refused exactly as before.

### A clone on Windows builds an image that starts

On Windows, where Git converts line endings by default, a clone checked every text file out with
CRLF. `docker build` copied the s6 service files into the image that way, so a service's `type`
read `longrun\r` and its scripts stopped on `set: -: invalid option`, and `bun run format:check`
failed on every file. `.gitattributes` now checks text files out with LF on every system. An
existing clone with nothing uncommitted picks this up after `git rm -r --cached . && git reset --hard`.

### A routine switched back on gets a fresh count of failures

A routine that fails ten times in a row is switched off, and someone has to switch it back on.
- **Before:** the failure count ignored that, so the first failure after re-enabling counted as the
  eleventh. The routine was switched straight off again with "failed ten times in a row", and the
  first-failure message never appeared.
- **Now:** failures are counted from when the routine was last switched on, recorded in a new
  `routines.enabled_at` column. The migration sets it to the time of the upgrade, so any failure
  streak already under way starts again from zero at that point. Adds migration
  `0051_routine_enabled_at`.

### Generated workspace files can be downloaded intact

`GET /api/computers/:botId/files/download?path=...` streams a generated file as an opaque
attachment instead of returning the 64 KB UTF-8 text extract. Downloads use the separate
`computer_download_file` / `download_file` permission, remain confined to the Bot workspace, are
capped at 100 MiB with `413`, and are recorded on the computer audit trail. Switching off **Cloud
computer use** under Admin → Enterprise refuses downloads as it refuses reads. Existing read, list
and write APIs are unchanged.

### Bots work as coworkers

A Bot can now carry on without anyone watching it. It runs standing **Responsibilities** fed by
schedules, signed webhooks, GitHub, Linear, Sentry, PagerDuty, inbound email and Slack messages,
drives its own computer while the app is closed, and keeps its browser profile, cookies and files
across restarts. Its questions and approval requests reach the person who owns the conversation in
Slack or Microsoft Teams (through OpenTag), by text message or by push, and the conversation
resumes when they answer; charts reach Slack and Teams as native charts. **Reachability** links
each of those places to a conversation.

Approvals become one personal flow across the browser, connected apps, shell, files, the host and
remote Bots, with custom rules, auto-review and host command modes (**Approvals**). Bots can
message each other, share a group conversation with attributed speakers, and be published to
teammates as **Team Bots**. **Memory** imports facts from connected apps with their source, and
optional background research suggests next steps. A browser demonstration can be recorded and
turned into a skill. Administrators get capability toggles, SSO-required sign-in, SCIM, network
egress policy, action recording, OpenTelemetry export, and **Passwords** with private sign-in
requests.

Upgrading runs migrations `0048_coworker_parity`, `0049_coworker_parity_lanes` and
`0050_review_fixes`.

### A Bot's computer refuses the network until its policy arrives

A computer used to allow every connection until the server had pushed its Bot's network policy,
which left up to 30 seconds of unfiltered access after every wake. It now refuses until the policy
arrives, and the server pushes it as the computer wakes. Cloud metadata and link-local addresses are
refused in every mode, including `allow_all`, and the browser's WebRTC traffic now goes through the
filter instead of around it. A computer run without an API server can set
`EGRESS_POLICY_REQUIRED=0` to keep the old behaviour.

### Parallel Search is in the plugin catalogue

Two catalogue entries reach Parallel's public-web search and extraction at
`https://search.parallel.ai/mcp`: **Parallel Search**, anonymous with provider-managed limits, and
**Parallel Search (API key)**, which sends a deployment credential as a bearer token. Nothing is
granted automatically. When a Bot holds both `web_search` and `web_fetch`, the built-in Bot guidance
describes them for public-web research, and the fintech example's Research Desk ships a
`research-public-web` skill that declares them. See
[Public-web research with Parallel](docs/parallel-research.md).

### `lodash-es` is pinned to the patched 4.18.0

A root `overrides` entry pins the transitive `lodash-es` to 4.18.0, the patched release, wherever a
dependency pulls it in.

### Provider and Bot lookups ignore inherited object properties

Unknown names such as `constructor` and `__proto__` no longer return an inherited
JavaScript object as a provider or Bot entry. Unknown providers return no spec, and
missing Bots raise the existing startup error. Configured providers and Bots are unchanged.

### A malformed `%` in a stream URL no longer returns a 500

A request to `/api/computers/<id>/stream` whose id held a broken percent-escape, such as `%zz`,
made the server throw and answer 500. It is now treated as not matching the stream route and goes
through normal routing. Valid ids behave as before.

### `start.sh` names the port to change on macOS

When the API server's or the app's port was held by another process, `start.sh` was meant to say
which setting to change, such as `Re-run with SERVER_PORT=<free port>`. On macOS, whose bash is
3.2, the run ended on `bad substitution` before printing it, because the hint upper-cased the
name with a bash 4 expansion. It is upper-cased with `tr` now, so the hint prints on either bash.

### `start.sh` starts the Docker services on Compose v5

On Docker Compose v5, `bash scripts/start.sh` stopped at
**1/4 Docker services** with `failed to get console: provided file is not a console`. The script
sends compose's output to `/dev/null` while its errors still reach the terminal. Compose saw that
terminal, chose its interactive build display, and could not draw it. The script now asks compose
for quiet progress through `COMPOSE_PROGRESS`, which older Compose versions ignore, so nothing
changes where it already worked.

### The skills pages say when the skills could not be read

When `GET /api/plugins` failed, **Agent Skills** said "You don't have any skills yet.", **Admin →
Skills** said "No skills yet.", and opening a skill to edit said "That skill no longer exists, or it
is not yours to edit.", to people who may have written a dozen. They now say the skills could not
be loaded. A list that arrived empty still reads as before, and a failed refetch over a list already
on screen keeps that list.

### A coworker can be pinned to the top of the Agents screen

A coworker's Manage tab has a **Pin** switch beside Hide, and pinned coworkers move into a
**Pinned** section at the top of `/agents`. Like hiding, pinning is personal: it changes nothing for
anyone else. It is stored next to `hidden_at` in `agent_preferences` as a new `pinned_at` column
(migration `0047_agent_pinning`), and each write sets only its own column, so pinning a hidden
coworker keeps it hidden and it comes back pinned when unhidden. `POST /api/agents/:id/pin` and
`/unpin` record `bot.pinned` and `bot.unpinned` on the trail, as hiding does.

### A hidden coworker can be found again on the Agents screen

Hiding a coworker took it off both lists on `/agents`, and Unhide is only in the coworker's dialog,
which only its card opens, so a hidden coworker had no way back short of typing its id into the
address bar. The screen now ends with a collapsed **Hidden** section listing them, each card opening
the dialog as before. It appears only when something is hidden. Hiding still changes nothing for
anyone else, and nothing on the server changed: the screen reads the `GET /api/agents?hidden=true`
list the server already served.

### A connector's own pages say when the plugin list could not be read

When `GET /api/plugins` failed, a connector's admin page said "Not a plugin", a tool's page said
"This deployment has not enabled that connector.", and a person's connected-account page said "This
is not a service you connect for yourself.", each about a connector that may be added and granted
right now. They now say the list could not be loaded, as the per-Bot grant page beside them already
did. A list that arrived without the connector still reads as before.

### Boundaries says when the policy could not be read

When `GET /api/computers/policy` failed, the Boundaries screen showed its title over nothing, for as
long as it was open. It now says "The boundary could not be read.", or the server's own reason, as
it did before the screen's read moved into a query.

### Browser controls are visible in chat and the Computer sidebar

Channel chats and standalone Bot chats now have a labeled Computer button and always-visible
Take control or Hand back controls. The same ownership state is shown in the chat, live Computer
sidebar, and full-size viewer. Standalone Bot chats can open the current live browser alongside
the conversation without losing the selected Bot or chat history.

### An administrator cannot grant a skill nobody has written

`POST /api/plugins/grants` checked that a skill existed for everybody except an administrator, whose
grant was stored whatever it named. A Bot's skills are read by slug alone, so the row waited for
whoever wrote a skill under that name next, and on a Bot the deployment shares that was one person's
instructions answering everybody. It is now refused with "There is no skill called …", as a grant
naming no app already was. Revoking one by hand still works.

### A remote Bot keeps answering when it asks for a learned skill that is not there

With Automatic Learning delivering skills, a Bot reached at an AG-UI endpoint (every shipped Bot
except a built-in one) ended the whole turn with "Skill is unavailable." in place of an answer when
its model asked for a skill by a name the snapshot does not hold, for a file the skill does not
list, or sent arguments that were not JSON. A built-in Bot's model is handed that sentence as the
call's result and carries on. A remote Bot's model now gets the same result and carries on too.

### An app or skill cannot be granted to a Bot that does not exist

An administrator's `POST /api/plugins/grants` for an app or a skill checked that the app or skill
existed but not the Bot, so a mistyped Bot id reached the insert, failed on the `plugin_grants`
foreign key, and answered 500 with no body. It is now refused with "There is no such Bot.", the
sentence the `bot` kind already used, and nothing is stored. Revoking still checks nothing.

### A malformed OAuth client is refused with a 400, not a 500

`POST /api/plugins/servers/:id/oauth-client` called `.trim()` on the client id and secret without
checking they were strings, so `{"clientId": 12345, "clientSecret": "s"}`, or a secret of `{}`, threw
outside the route's try and answered 500. It now answers the same 400 as an empty value, as the
other plugin routes do for their own fields, before the store or the audit trail is touched.

### Browser challenges can be handed to a person without losing the Bot's page

Bots pause for actionable browser challenges and resume from a fresh page snapshot after an explicit
handback. Requests survive viewer reconnects and distinguish completion from cancellation, expiry,
or an interrupted browser session. Managed browsing now uses full Chromium in headless or headed
mode. Local API deployments can opt into installed Chrome with dedicated per-Bot profiles, the same
in-app viewer, a loopback-only computer endpoint, and host shell execution disabled.

### A hidden Bot's app grants stay on the Plugins screens

Hiding a Bot from your own roster took it off the Plugins screens too: its row went from By Bot and
from each tool's switches, the counts could read "3 of 2 Bots", and its own page said there was no
such Bot. Its grants stayed in force, and nothing on any screen could take them away. The Plugins
screens now follow the rule the Handoff panel already does: a hidden Bot is shown when it holds one
of the grants the screen is about, marked "Hidden from your roster", and its own page draws its
grants. Nothing on the server changed.

### Revoking a function from a component that does not exist answers 404

`DELETE /api/components/:name/functions/:function` was the one grant write that did not check the
component exists. Against a name nobody has, it deleted nothing, answered `revoked: true` and wrote a
`component.function_revoked` row naming a component that was never there. It now answers 404 and
writes nothing, as granting a function and withholding a component already do. A function grant
cannot outlive its component, so there is no stored row this stops anybody removing.

### A wiped or restarted shared computer no longer leaves refs pointing at the dead page

Snapshots are ordered on the run of the browser that took them as well as the generation, so a
computer that is replaced cannot have its old page mistaken for its new one. That ordering was
reaching only the deployments that give each Bot its own container or sandbox, because the run was
read off the infrastructure and the deployment with one shared computer has none to read.

Two failures followed there, and both are fixed. A snapshot still in flight when somebody pressed
Reset brought the wiped page back, and the boundary went on deciding about its elements: a rule about
"Confirm transfer" firing on a click nowhere near one, or failing to fire on one that is. And a
computer that restarted counted generations from one again, so its first snapshots were dropped as
stale and refs kept resolving against a page nobody was on until the counter climbed back past it.

The computer now mints a run for each Bot's browser session, mints a new one when the Bot is reset,
and answers which run it is on. Nothing changes for a deployment that already reports one, and a
computer too old to answer leaves the ordering exactly where it was rather than refusing anything.

### `scripts/start.sh` no longer needs python3

The runtime health check in step 3 was a `python3` heredoc. On a machine without Python, and on
Windows, where `python3` is usually the Microsoft Store alias that exits 49, the run stopped there
with the server and worker up and the app never started. The check now runs in Bun, which the
script already requires, with the same output and exit status, and `python3` is gone from the
prerequisites in `docs/development.md`.

### An MCP tool that answers with a resource link is no longer read as an empty name

A tool that points at a file or a page often returns a `resource_link`: a URI, a name, and a
sentence of what it is, rather than the contents themselves. That part was named `[resource_link]`
and the URI was dropped, so the model was told a link arrived and never shown where it went. A
search that answered with pages produced no page it could open. The URI, name and description are
now read, each on its own labelled line. The URI leads and the name and description are bounded, so
a long name cannot push the pointer past the result cap; a server's `title` is shown over its `name`
when it gives one. A part that already carried text is unchanged.

### The Microsoft Agent Framework Bot answers on a plain OpenAI key

Picked with an OpenAI key, the Microsoft Agent Framework Bot failed every run with "Connection
error.". Compose writes `OPENAI_BASE_URL` empty when the choice is a plain OpenAI key, and the
OpenAI SDK only defaults an absent URL, so it was given "" as the address. The Bot now falls back to
`https://api.openai.com/v1` for an empty value, as its Anthropic branch already did for
`ANTHROPIC_BASE_URL`. An OpenAI-compatible endpoint is unchanged.

### `OPENBOT_ONE_COMPUTER_EACH=false` in `.env` is honoured by `start.sh`

`scripts/start.sh` read `OPENBOT_ONE_COMPUTER_EACH` from the environment alone, so the line that
`docs/configuration.md` tells people to put in `.env` was ignored: the supervisor was still started
and the server still told to give each Bot its own computer. It now reads the key as it reads every
other setting, the environment first, then `.env`, then the default of `true`.

### Skill selection keeps capabilities named across multiple JSON replies

When a model wraps its skill choice in prose or sends a revised JSON object, OpenBot reads each
complete `skills` list and offers the union of the named skills' granted tools. This also works with
Anthropic's OpenAI-compatible endpoint, which may ignore the request for bare JSON. Previously a
reply containing multiple objects fell back to offering every tool; replies with no valid `skills`
list still do.

### The AG2 Bot answers on a plain OpenAI key

Picked with an OpenAI key, the AG2 Bot failed every run. Compose writes `OPENAI_BASE_URL` empty when
the choice is a plain OpenAI key, and the OpenAI SDK only defaults an absent URL, so it was given ""
as the address. The Bot now falls back to `https://api.openai.com/v1` for an empty value, as its
Anthropic branch already did for `ANTHROPIC_BASE_URL`. An OpenAI-compatible endpoint is unchanged.

### The live screen keeps reconnecting after it has recovered

A dropped live screen retries five times, waiting half a second, then one, two, four and eight, and
then asks for Retry. The count of retries never went back to zero after a retry worked, so a screen
left open through five short drops over an afternoon gave up on the sixth, although each had
recovered within a second. The count now starts over once a reconnected screen shows a frame again,
so only five failures in a row end in Retry.

### A failed save of a Bot's browser control leaves no copy behind

The computer keeps who holds a Bot's browser, and its handoff requests, in one file per Bot under
the profiles volume, written to a temporary file first and renamed over it. When the write or the
rename failed, the temporary file stayed, a readable copy of that state beside the real one, and
every later failure added another. It is now removed whether or not the save succeeds, as the
learning setup and the model sign-in file already do.

### Every Bot's provider defaults live in one spec file

`shared/model-providers.json` now holds the provider facts and the default provider and model of
the thirteen Bots that read it: the three TypeScript Bots through `shared/model-providers.ts` and the
ten Python Bots through `shared/model_providers.py`. The Claude Agent SDK Bot does not read it.
`BOT_PROVIDER` and `BOT_MODEL` still win over both, and each Bot keeps its existing default,
including Mastra's `gpt-4o-mini`. Moving a Bot to a different model is one row in one file.

Both loaders check the file against their own list of providers and refuse in the same words, so a
wrong row now stops all thirteen at startup, naming the key, where the Python Bots used to start
clean and meet it at their first model call. The Mastra Bot also refuses a `BOT_PROVIDER` it does
not recognize (such as `google`) instead of quietly answering through OpenAI with a different model.

Compose used to substitute `gpt-5.5` for `agent-langgraph` whenever `BOT_MODEL` was unset, whatever
`BOT_PROVIDER` named. It now passes the unset value through, so the Bot's own row answers: an OpenAI
deployment keeps `gpt-5.5`, and a Google or Anthropic one stops being handed a model its vendor has
never heard of. The picked harness in Compose now also receives `GOOGLE_API_KEY` and
`GOOGLE_GENERATIVE_AI_BASE_URL`, so a harness picked on `BOT_PROVIDER=google` has its key.

### Automatic Learning, on by default

Every shipped Bot can now contribute completed conversations to a CopilotKit Intelligence Learning
container and receive the skills published from it. **Admin → Automatic Learning** chooses a default
container, overrides or excludes individual Bots, and pauses Learning. Chat, channels, routines and
handoffs all follow the same settings.

Learning is on unless an administrator has saved it off, and a saved off stays off. It collects and
delivers nothing until a container exists in the Intelligence project and is assigned:
`bun scripts/setup-learning.ts` creates or reuses one called `openbot` and writes it to `.env`, or
set `CPK_INTELLIGENCE_LEARNING_CONTAINER_ID` (Helm: `config.learning.containerId`), or enter it on
the Admin page. OpenBot starts and chats without one. Skills are reviewed and published in
Intelligence; nothing is approved automatically. See
[Automatic Learning](docs/automatic-learning.md). Adds migration `0046_automatic_learning`.

### Dictate messages and talk to a coworker in a live voice call

Deployments can configure transcription separately from their Bots' models, with a waveform composer
for recording, cancelling, transcribing, or sending speech. Optional OpenAI Realtime and Grok voice
adapters add a floating call widget. The live model handles conversation directly and delegates tools
and actions to the existing Bot in the same thread. Ending a call saves its transcript and a short
summary; later voice calls and typed messages receive that history. Calls start silently, and muting
affects the person's microphone. See [configuration](docs/configuration.md#live-voice-calls).

Voice summaries use the configured chat provider, including Anthropic keys and Claude or ChatGPT
plan sign-in. Retrying a failed summary refreshes its sidebar preview without replacing newer
activity. A call the voice service turns down says why, such as "The voice service is busy. Please
retry shortly.", and a call that cannot be saved says "Could not save this voice chat." and stays on
its card to retry. Caps on a call's context, captions and answers cut between characters, never
inside an emoji.

### The Pydantic AI Bot answers on a plain OpenAI key or an Anthropic key

Picked with either key, the Pydantic AI Bot failed every run. Compose writes the endpoint the choice
did not need as empty (`OPENAI_BASE_URL` for a plain OpenAI key, `ANTHROPIC_BASE_URL` for an
Anthropic key), and Pydantic AI builds each provider's client from the environment, so the SDK was
given "" as the address. The Bot now removes an empty value before building the model, as
`agent-langgraph-agui` already does, so the SDK uses its own endpoint. A real endpoint is unchanged.

### The Langroid Bot answers on a plain OpenAI key

Picked with an OpenAI key, the Langroid Bot failed every run with "Connection error.". Compose
writes `OPENAI_BASE_URL` empty when the choice is a plain OpenAI key, and the OpenAI SDK only
defaults an absent URL, so it was given "" as the address. The Bot now drops an empty
`OPENAI_BASE_URL` before it builds its client, as it already does for an empty `OPENAI_API_KEY`.
An OpenAI-compatible endpoint is unchanged.

### Find older conversations and keep chat preferences across devices

The sidebar loads older conversations as the person scrolls. Settings save the choice to emphasize
the agent or thread name in the database, with a preview. Agent directory cards have more space,
connected accounts use individual entries with stored app logos, and browser steps appear in a compact
expandable group instead of filling the conversation with screenshots.

## 0.0.15

### A model provider's own sign-in can stand in for an API key

`OPENBOT_MODEL_OAUTH_FILE` names a credential file holding a Google or xAI OAuth grant. Set it and
the server mounts `POST /api/model-provider/v1/chat/completions`, which answers an ordinary Chat
Completions request using that grant, refreshing the access token 120 seconds before it expires and
again on a provider 401, and persisting the rotation under a lock the writer and the desktop share.
Leave it unset, which is every deployment that does not set it, and the route does not exist.

The caller authenticates with a separate local bearer taken from that file, compared in constant
time, never with the provider's own token: a refresh token never leaves the server process. The file
itself is refused unless it is a regular file under 64KB owned readable by nobody else, and a Google
grant must name a quota project. The upstream host, path and headers are fixed, so nothing a caller
sends can redirect the request.

Google is reached through its native generation API rather than a compatibility endpoint, with a
translation layer that carries streaming, tool calls and their results, inline images and
function-call thought signatures across in both directions. An API-key connection is unchanged and
still uses the compatibility endpoint.

**A provider 403 no longer reads as an expired sign-in.** It usually means a missing project or
resource permission, which signing in again cannot fix, so only a 401 now raises "sign in again".

### Desktop setup shows progress, chooses its own local ports, and can sign in to a provider

Downloads report transferred bytes, every running step reports elapsed time, and running, completed
and failed stages are told apart. Back preserves the connections already entered.

OpenBot now chooses its local ports by binding them rather than assuming them, holds them until the
whole set is settled, and writes them to the deployment's `.env` so a restart keeps the same
addresses. That covers a port another program holds and a port Windows has reserved, neither of
which the old fixed defaults survived. A port that becomes unavailable between choosing and starting
now says so and asks for another Start, where it previously refused before trying.

Setup can create a CopilotKit project, and offers Google Gemini and xAI as API-key choices alongside
OAuth sign-in. Google sign-in requires this build's own registered desktop client and quota project,
set at build time or by environment variable, and refuses with a message saying so when it has
neither; xAI falls back to a public client and works in any build. `desktop/PROVIDER_OAUTH.md`
describes what a distributor configures.

A deployment left behind by an earlier installation can be detected and reset from the app, which
removes that deployment's database volume and nothing else.

Startup failures keep enough of the log to name the cause, with every secret value redacted, and
carry a support link a whitelabel build can point elsewhere.

### A Bot's image pull finds the Docker credential helper beside Docker

A Docker install whose credential helper sits next to the `docker` binary rather than on the desktop
app's own PATH failed the pull with a PATH error naming the helper. The directory holding the
resolved `docker`, and the directory holding what it points at when it is a symlink, are now appended
to the PATH the engine is invoked with. Appended, so an existing helper still wins, and the inherited
PATH is now kept rather than replaced, which it was not before.

### OpenBot starts only on the Bun it pins

An installed or cached Bun that is not the pinned version is no longer accepted, on install and on
every start, and OpenBot acquires its own copy instead. The version already on the machine is left
exactly as it is and simply not used.

### Organization sign-in survives a callback that arrives in pieces

The loopback listener that receives an organization or provider sign-in read the callback once and
gave up if the whole request had not arrived, and on Windows the accepted socket inherited the
listener's non-blocking mode, so a timeout did not apply. A good sign-in could be answered "Sign-in
did not match". Both paths now read until the request line is complete, with a real timeout.

### Compose file lists separate correctly on Windows

The separator between Compose files fell back to `:` everywhere, which is right on macOS and Linux
and wrong on Windows, where a drive letter contains one. It now follows the platform. This is
reachable on every platform now that a port overlay is passed, where before it was macOS only.

## 0.0.14

### A tool cannot be granted for an app this deployment has not added

Granting a Bot a connector's tool checked only that the person asking was an administrator, so a
grant naming an app that was never added was stored and then invisible — the page that reports a
grant nothing advertises is built from the connector's own row, and there was none. Adding that app
later put every such grant straight onto its Bots, with nobody having granted anything and nothing in
the trail saying so. The grant is now refused, naming the app. Taking a grant away is unaffected, so
a dead row an administrator can see is still one they can remove, and a tool a connector has stopped
advertising can still be granted: what a vendor lists today is not what somebody decided yesterday.

### The LiteLLM Bots keep the chosen provider on a model name that contains a slash

A model name the endpoint publishes with a slash in it — `qwen/qwen3-8b`, or the docs example
`openai/gpt-5.6-terra` — was treated as already carrying a provider. LiteLLM then took the first
half as the provider and sent only the rest, so a compatibility endpoint either failed with
`LLM Provider NOT provided` or received `gpt-5.6-terra` instead of the namespaced name. The ADK,
Strands, Agno, LlamaIndex and CrewAI Bots now keep the chosen provider in front, and the whole
model name reaches the endpoint.

### A Google Drive shortcut is read as the file it points at

Search and recent files return shortcuts as ordinary hits, and reading one by that id was refused
as a binary `application/vnd.google-apps.shortcut`. A document somebody had starred or filed as a
shortcut — the usual way a shared drive file is kept at hand — could be named and not opened. The
connector now follows the target once and reads that file the same way it would have if search had
returned it directly. A shortcut that names nothing, or another shortcut, is still declined.

### An MCP tool that answers in structuredContent is no longer read as empty

A tool that declares an output schema often puts the answer in `structuredContent` and leaves the
content list empty. That empty list was reported as "nothing was found", so the model filled the
gap from memory while the vendor had answered. The structured object is now read when the content
list had nothing to say. A tool that already sent text is unchanged.
The slash no longer names the provider on those five Bots, so a `BOT_MODEL` that relied on it to
reach somewhere other than `BOT_PROVIDER` is now read as part of the model name: `bedrock/…`,
`azure/…` and `openrouter/…` reach the provider `BOT_PROVIDER` names rather than the one written in
front of the slash. `BOT_PROVIDER` is the setting for that, and a model name written bare beside it
behaves as it did. The framework Bot `agent-langgraph` and the Langroid Bot are unchanged, because
neither read the slash that way.

### A Bot's computer no longer runs as root on Kubernetes

The image already builds `pwuser`, chowns `/workspace`, `/profiles` and `/app` to it, and the
all-in-one image drops to it through s6. A computer pod overrides the command to run the browser
process alone, so it never reached s6 and ran as uid 0. It now runs as `pwuser` in both the modes
this chart runs a computer in, `shared` and `sandbox`, with `HOME` and `BUN_INSTALL` set the way s6
sets them. `BUN_INSTALL` moves because its default is root-owned, and `bun add` in a Bot's shell
would otherwise stop working the moment the pod stopped being root.

**Kubernetes only.** The Compose and supervisor paths run `agent-computer/Dockerfile`, which builds
no such user and is still uid 0. That is the rest of the residual #261 named and is not this change.

**What it buys, and what it does not.** It is not a containment boundary against a Bot's own shell:
the image grants `pwuser` passwordless sudo for apt-get/apt/dpkg, which escalate to root by design,
and gVisor plus a computer per Bot remain the actual boundary. Nor does it change which Pod
Security Standard the pod meets: `runAsNonRoot` is a **restricted** control, not a baseline one,
and restricted also wants `allowPrivilegeEscalation: false`, `capabilities.drop: [ALL]` and a
seccomp profile, which are deliberately not set here for the sudo reason above. The pod met
baseline before this and still does not meet restricted after it. What it does buy is the org
policies and admission rules that reject uid 0 outright, that root-owned data stops accumulating
in the volumes, and that a bug yielding a constrained primitive lands as 1001.

**Before upgrading an existing release, two things.** The kubelet applies `fsGroup` only where the
volume plugin says it can: the EBS, PD and Azure Disk CSI drivers do, `hostPath` does not, and
hostPath is what rancher/local-path-provisioner hands out by default, which is the default
StorageClass on k3s. On storage that cannot, the computer now refuses to start and says so, rather
than coming up healthy with a browser profile Chromium silently replaced, which is what it did
before this release. Chown the directory, or set `computers.podSecurityContext: null`. And an
upgrade run with `helm upgrade --reuse-values` does not pick up a new key at all, so it keeps
running as root and says nothing; pass the value or drop the flag.

**In `computers.mode: sandbox`, existing Bots keep their old computer.** The server copies the pod
template into a Sandbox when it creates one and never updates it, so only Bots created after the
upgrade run as 1001. The server does restart, because the template checksum changes, which makes it
look like the change landed everywhere. The only lever today is `reset`, which deletes that Bot's
volumes and its logins.

`fsGroupChangePolicy: OnRootMismatch` is set deliberately. Unset means `Always`, which walks every
file on every mount; a real Chromium profile is tens of thousands of small ones, and in `sandbox`
mode that pass would run again on every resume from idle.

### Which email domains may sign in, decided by the deployment rather than the provider

Nothing in OpenBot filtered who could sign in. `INITIAL_ADMIN_EMAILS` decides who is an
administrator once they are in, which is a different question. The providers do not answer it
either: `MICROSOFT_OAUTH_TENANT_ID` defaults to `common`, which is any Microsoft account including
personal ones, and Okta has no equivalent setting. So a deployment reachable from the internet
admitted anybody who could complete the flow, as a non-administrator with access to its Bots.

`SIGNIN_ALLOWED_EMAIL_DOMAINS`, or `config.allowedEmailDomains` on the chart, names the domains
admitted. It is checked against the address the provider returns, in the same two hooks the removal
deny list uses, so it covers a first sign-in and an account that already exists. A refusal writes a
`session.refused` audit row naming the reason. Empty means no opinion, so nothing changes for a
deployment that does not set it.

Matching is exact with no wildcards, for the reason `AGENT_ENDPOINT_ALLOWED_HOSTS` gives:
`example.com` admits neither `sub.example.com` nor `evil-example.com`. Both sides go through the
same IDNA normalisation, so a list may be written `@Example.COM.` or in punycode and still mean
what it says.

**It is a filter, not a boundary, and the deployment is told so.** OpenBot does not require a
verified address, and Entra's `email` claim comes from a directory attribute that the signing-in
tenant's own administrator writes. Two consequences, both now enforced at start-up rather than
documented and hoped for:

- Naming domains while `MICROSOFT_OAUTH_TENANT_ID` names no directory is **refused**. That is
  `common`, and equally `organizations`, which Microsoft describes as admitting any work or school
  account in any directory, and `consumers`. Anybody can create a tenant and write your domain into
  their own user, so the list would refuse the honest and admit the rest while reading as a
  control. Set your directory GUID.
- A list that names nothing, which `SIGNIN_ALLOWED_EMAIL_DOMAINS=@` and a stray `.` both produce, is
  **refused**. It is a non-empty list no address can match, and left to run it turns every visitor
  away with nothing said at boot.

A deployment that names no domains and leaves the tenant multi-tenant warns instead of refusing,
because genuinely multi-tenant is a real deployment.

### No sign-in cannot be combined with a public address

`OPENBOT_SINGLE_USER=true` admits every request as one administrator. The flag is how somebody says
they meant that, and it still is. What was missing is the second question: one administrator and no
sign-in is a thing you run where only you can reach it, and nothing checked the address.

It is now refused alongside an `OPENBOT_PUBLIC_URL`, `OPENBOT_APP_URL` or `TRUSTED_ORIGINS` entry
that the public internet routes to, and the refusal names the address it objected to. This is the
rule the chart already applies twice, in `validation.yaml`, moved to where a deployment that never
goes near Helm is asked it too: `.env.example` ships the flag on so that a clone runs, and README's
"Deploy it" hands that same `.env` to `docker run`, where the only thing separating a laptop from a
server is an address.

**Public, not "not loopback", and the difference is most of the deployments this flag has.** A home
server at `192.168.1.10`, a Tailnet address, a VPN address, `openbot.local`, a bare hostname with
no dot in it: none of those is loopback and none of them is a stranger's to reach. Refusing them
would refuse the feature's own audience, and the only way out would be to turn off the flag that
describes what the operator is doing. Those run, and warn once at boot that anybody on that network
is the administrator. Loopback is silent. A value that cannot be parsed as a URL counts as public,
because a value nobody could read is not one anybody checked.

Nothing on loopback changes, so the local workflow the flag exists for is untouched, and neither is
the chart's `config.singleUser` trial mode, which sets no public address. A deployment naming an
external authority through `OPENBOT_ORGANIZATION_AUTH_URL` is unaffected too: the authority wins
before this is consulted. Explicitly NOT gated on `NODE_ENV`: the image and the chart both set it
to `production` for every deployment including that trial, so it says nothing about who can reach
a deployment.

`docs/architecture.md`, `docs/deployment.md` and `docs/configuration.md` all described the old rule
and now describe this one.

### The EKS cluster recipe puts the node's IAM role out of a Bot's reach

A Bot has a shell, and a shell reaches whatever its pod reaches, including the instance metadata
service at 169.254.169.254 that hands out the node's IAM role. The NetworkPolicy excepts that
address, but it is off by default and does nothing on EKS until the VPC CNI is told to enforce it,
so the cluster config in the chart README now sets `disableIMDSv1` and `disablePodIMDS` on the node
group, which closes it at the node whatever the CNI is doing.

`disablePodIMDS` is the line that does the work: it sets the hop limit to 1, and that governs the
IMDSv2 token PUT, so a pod one hop further out than the node cannot get a token. `disableIMDSv1` is
written beside it to say so out loud rather than to change anything, because eksctl defaults it to
true and sets `httpTokens: required` for either flag. Pods on the cluster network are covered; one
running with `hostNetwork: true` is on the node and is not.

**It costs something, and the recipe says so.** The EBS CSI driver reads instance metadata from
IMDS, and its own documentation asks for a hop limit of 2 or greater in a containerized environment.
A hop limit of 1 also rules out `MutableCSINodeAllocatableCount`, which requires IMDS to be the
driver's metadata source. Take these two lines out if you need that.

Nothing in OpenBot wants pod-level IMDS: the chart reaches AWS through IRSA. Documentation only; no
chart template changed, and an existing cluster is unaffected until its node group is recreated.

### A large text file says so on the composer before it is sent

The model reads the first 120,000 characters of an attached text file and the rest is dropped. The
part said so to the model and nothing said so to the person attaching it, so a 1MB CSV was answered
from roughly a tenth of itself with nothing on screen to explain the answer. A staged file over that
ceiling now carries "may be cut" beside its size, with the exact number on hover. Warned, never
refused: the whole file is still uploaded and still stored.

Whether a file is text is decided by what the server read in its bytes, not by what the browser
called it, so a file the browser labelled an image and the server read as text is warned about too.
That is the file the old reading would have missed.

### ADK and Langroid Bots can call the tools OpenBot supplies

Both answered text prompts on an OpenAI key and neither could reliably use the tools the deployment
supplies them, so a Bot on either harness could talk but could not act. ADK now registers the
documented `AGUIToolset`. Langroid now sends each run's tool schemas and its complete message
history, tool results included, so a tool's answer reaches the model that asked for it. Each run
keeps its own tool and history state.

### Built-in Bots carry a model provider's sign-in failure through as itself

A built-in or LangGraph Bot whose model credential had expired ended the run as a generic failure,
which reads as the Bot being broken. The run now ends with `OPENBOT_MODEL_AUTH_REQUIRED` and says to
sign in to the model provider again.

The built-in Bot's tool loop also moved to the server, which owns the grants that decide what a tool
may do. The harness is given model input alone, and a tool result is resolved against the call that
produced it, so a Bot can carry a multi-step task across several tool calls rather than losing the
thread after the first.

### A deployment can name an organization authority that decides who it admits

`OPENBOT_ORGANIZATION_AUTH_URL` points at an OpenBot deployment configured with Google, Microsoft or
Okta, which verifies who somebody is and what roles they currently hold. It is separate from any
Intelligence connection, and the authority keeps its own secrets.

Naming one settles the sign-in question by itself: it wins over `OPENBOT_SINGLE_USER`, so a
deployment carrying a leftover single-user flag admits verified people rather than admitting
everybody as one administrator.

### A coworker can be a file of its own

The example package declared every coworker in one `agents.yaml`, so adding one meant editing a file
somebody else was editing too, and handing somebody a coworker meant handing them a fragment to
paste into the middle of theirs. A package may now also keep a coworker per file in an `agents/`
directory beside `agents.yaml`, and both are read. A package that keeps everything in `agents.yaml`
loads exactly as before. A file holds the coworker on its own or a list under `agents:`, only
`.yaml` and `.yml` are read, and files are read in filename order. Two declarations of the same id
stop the server and both files are named, rather than one quietly winning on the order a directory
was listed in. The directory is in the package checksum, so a coworker added or edited there is a
package change a running deployment notices.

### Ten more example coworkers, each doing one job

The example package shipped three coworkers, which is enough to prove the format and not enough to
give anybody ideas, and writing a `role_description` cold is the part that decides whether a
coworker answers usefully or vaguely. Ten more ship in `examples/fintech/agents/`, one file each:
reading an expense claim against the policy as written, turning a meeting note into the follow-ups
actually in it, drafting release notes from what shipped, triaging a support ticket, answering a new
starter from the handbook, writing a brief that names what it could not find, writing up an
interview with question, answer and observation kept apart, handing an on-call shift over from the
record, assembling what is known before a renewal decision, and grouping customer feedback into
themes it can cite. Each says what the job is, what the coworker must not do, and what to say when
it cannot find something. They grant nothing: a coworker names skills, a skill names tools, and what
it may call is what an administrator has granted. Delete the ones you do not want.

### Built-in and Mastra Bots can run on Anthropic API keys

The example built-in Bots and the Mastra Bot now use the selected model provider instead of
assuming OpenAI. A deployment with `BOT_PROVIDER=anthropic`, `BOT_MODEL=claude-sonnet-4-5` and an
Anthropic key routes built-in model calls, tool selection and Mastra runs through Anthropic's native
API. Source startup no longer waits for the unused OpenAI-only sample when Anthropic is selected.

### The Agno Bot answers on an OpenAI key

Picked with an OpenAI key, the Agno Bot failed every run before reaching OpenAI. Agno sends a
temperature and a `top_p` with each request, and LiteLLM refuses both for `gpt-5.5`, the model
Compose passes when the setup screen names none, so the run ended in `UnsupportedParamsError`. A
parameter the model does not take is now dropped instead, the way the LlamaIndex Bot already does
it. The Anthropic key and an OpenAI-compatible endpoint behave as before.

### The Pydantic AI Bot starts on an Ollama model named with its tag

Ollama names every model with a tag after a colon, as in `llama3.1:8b`, and that is the name the
setup screen passes on for an OpenAI-compatible endpoint. The Pydantic AI Bot took any colon in the
model's name to mean the name already carried a provider, so Pydantic AI read `llama3.1` as one,
refused it as unknown, and the Bot never started. A model's name now carries a provider only when it
begins with the chosen provider's own, as in `anthropic:claude-sonnet-4-5`.

### The Langroid Bot starts on an Anthropic key

Picked with an Anthropic key, the Langroid Bot exited on startup asking for an OpenAI key. It names
a model from any provider but OpenAI through litellm, which its image did not install, and Langroid
builds an OpenAI client for such a model all the same, from the `OPENAI_API_KEY` Compose writes
empty when the choice was not OpenAI. The image now installs Langroid's litellm extra and an empty
OpenAI key is treated as none, so the Bot starts and answers with the Anthropic model chosen.

### The AG2 Bot answers on an Anthropic key

The AG2 Bot built an OpenAI client whatever the setup screen chose, and read `BOT_MODEL` but never
`BOT_PROVIDER`. Picked with an Anthropic key, every run failed asking for an OpenAI key, because
Compose writes that one empty when the choice was Anthropic. It now reaches Anthropic through AG2's
own Anthropic client when that is the provider chosen, and OpenAI or an OpenAI-compatible endpoint
as before otherwise.

### The Microsoft Agent Framework Bot starts on an Anthropic key

The Microsoft Agent Framework Bot built an OpenAI client whatever the setup screen chose, and read
`BOT_MODEL` but never `BOT_PROVIDER`. Picked with an Anthropic key, it exited on startup asking for
an OpenAI key, because Compose writes that one empty when the choice was Anthropic. It now reaches
Anthropic through Agent Framework's own Anthropic client when that is the provider chosen, and
OpenAI or an OpenAI-compatible endpoint as before otherwise.

## 0.0.13

### Fresh desktop setup installs its runtime before sign-in

Desktop setup installs local software before asking for an AI connection. Fresh Mac Podman
installations no longer duplicate stack port bindings. The shared installer downloads verified
prebuilt Bun binaries without developer tools; Linux setup also installs its native Podman runtime
and certificate bundle. (#604)

### Ctrl+B shows and hides the sidebar on a layout that does not write Latin letters

The sidebar toggle's tooltip names Ctrl+B, or ⌘B on a Mac, and the shortcut was recognised by the
character the key writes. On a Russian or Greek layout the B key writes "и" or "β", so the shortcut
did nothing there. It is now read the way the app's own shortcuts read it since Shift+N was fixed
for the same layouts: from the physical key when the layout writes a character outside ASCII there.

### Scrolling a Bot's browser no longer scrolls or zooms the page around it

While somebody drives a Bot's browser, a turn of the mouse wheel over its screen is sent to it, and
the screen was meant to keep the wheel from also acting on the app. React attaches its wheel handler
as a passive listener, which a browser does not allow to do that, so the wheel scrolled the frame
holding the Bot's screen along with the Bot's page, and Ctrl with the wheel zoomed the app. The
wheel is now handled by a listener that can hold it, so it reaches only the Bot's browser.

### Typing into a Bot's browser no longer triggers the app's own shortcuts

While somebody drives a Bot's browser, every keystroke is sent to it. The app's shortcuts listen for
keystrokes too, and they heard each one first, so typing a capital N into the Bot's browser, as in
"New York", started a new chat and took the person away from the Bot mid-word, and Ctrl+B there
also showed or hid the sidebar. A keystroke sent to the Bot's browser now reaches only the Bot's
browser. Escape still closes the view, and the paste shortcut still pastes.

### The Python LangGraph Bot on Anthropic answers after a skill was picked

A skill somebody picks reaches the Bot as a system message just ahead of their message, and it
stays in the conversation. Anthropic takes one system prompt, and its LangChain integration refuses
a system message that comes after a turn of the conversation, so with `BOT_PROVIDER=anthropic`
every run in that conversation failed from then on, before the model was asked. On Anthropic the
Python LangGraph Bot now puts every system message ahead of the conversation, in the order given,
where the integration joins them into its one prompt. Runs on OpenAI and Gemini are unchanged.

### The LangGraph Bot answers on Anthropic and Gemini

With `BOT_PROVIDER=anthropic` or `BOT_PROVIDER=google`, the LangGraph Bot answered nothing: every run
ended in an error before the model was asked. Those two providers take one system prompt, at the top,
and the Bot handed its model several: its own guidance, the context the app sends, and the
coworker's standing role, which the server puts at the head of every run. The provider's LangChain
integration refused the second one. On those two providers the Bot now folds them into one system
prompt, in the same order, and a skill picked for a message joins it. Runs on OpenAI are unchanged.

### The proof-of-concept Bot reads a model name set with whitespace around it

A `BOT_MODEL` carrying a leading space reached this Bot as it was written. Its startup check refuses
`gpt-5.6-*`, which rejects function tools on the API this Bot speaks, and that check matches from the
start of the name, so a padded one walked past it: the Bot started, reported healthy, and answered
nothing at all on the first turn that used a tool. An empty value was read the same way and asked the
provider for a model with no name. Both now fall back to the default, and the name is used trimmed.
`.env` was never a route to this — Compose, Bun and the desktop shell each strip the value first — so
it reached only deployments that set the variable directly, such as a Kubernetes manifest or
`docker run -e`.

### Pasting into a Bot's browser works on a layout that does not write Latin letters

While somebody drives a Bot's browser, Ctrl+V or Cmd+V is left to the local page so its paste event
can send the clipboard text across. The shortcut was recognised by the character the key writes,
and on a Russian or Greek layout the V key writes "м" or "ω", so the keystroke went to the Bot's
browser instead and nothing was pasted. The V is now read the way the app's own shortcuts read it
since Shift+N was fixed for the same layouts: from the physical key when the layout writes a
character outside ASCII there.

### Reading a large file from Google Drive no longer downloads all of it

`read_file_content` shows a Bot at most the first 20,000 characters of a file, but it downloaded the
whole file and held it in memory before cutting it. A 200 MB text file raised the server's memory by
more than 600 MB for one call, on the process that serves everybody else. The connector now stops
reading once it has more than it can show and cancels the rest of the download. What the Bot is shown
is unchanged, except that the note on a cut file no longer gives the file's full length, which is no
longer known.

### A Bot reads the text an MCP server returns as an embedded resource

A tool result can carry an embedded resource, and a text resource holds content, such as a file the
server read. The MCP connector passed text parts to the Bot and named every other part, so a text
resource reached the model as `[resource]` and its contents were dropped. GitHub's MCP server answers
`get_file_contents` for a text file this way: the Bot was told the download worked and never saw the
file. The text of an embedded resource is now passed on like a text part. A resource that carries
bytes is still named.

### The Google Drive connector reaches files in shared drives

Drive leaves shared drive items out of any `files.get` or `files.list` request that does not say it
supports shared drives, and none of the connector's requests said so. A document the person could
open in a shared drive was "File not found" to `get_file_metadata` and `read_file_content`, and never
appeared in `search_files` or `list_recent_files`. Those requests now say they support shared drives,
and the listings ask for shared drive items. Listings keep Drive's default `user` scope rather than
searching every shared drive.

### Google Drive search and recent files leave out what is in the trash

Drive's `files.list` returns trashed files unless the query excludes them, and neither `search_files`
nor `list_recent_files` did. A document somebody had thrown away came back to the Bot as a match or
as a recently changed file, with nothing in its line to say it was in the trash, so the Bot could
answer from it as though it were current. Both now ask Drive to leave the trash out. Reading a file by its
id is unchanged.

### New conversations are still named once some older ones could not be

Every pass of the job that names conversations offered at most twenty of those still without a name.
A conversation it had tried and could not name, for example because the model answered with no text
or the conversation opened with only an attachment, keeps no name, so it stayed among those twenty
and took a place on every pass, although offering it again did nothing. Once enough of them had built
up, a new conversation could miss out on every pass and keep showing its plain name in the sidebar.
A pass now skips any conversation that the job already holds work for, so new ones get a place. One
it could not name is still tried again later, as before.

### An offboarding one app refuses still records the apps that answered

Removing somebody withdraws each brokered account they connected. When the broker refused one of
those apps, the whole act stopped before anything was recorded: apps already withdrawn at Composio
kept their `composio_connections` row and left nothing on the trail saying the account had ended,
and the retry that #574 made the recovery then asked again, was told there was nothing to withdraw,
and wrote `vendorRevocationRequested: false` about a withdrawal this deployment had asked for and
got. Each app is now asked, recorded with the answer it actually gave and its row removed, and only
the apps that were refused are left standing for the retry. The act still fails and still answers
500, so a refusal is as loud as it was.

### Paging the audit trail no longer skips rows written in the same millisecond

`GET /api/admin/audit-events` hands out a `nextCursor` built from the last row's timestamp, which the
server read at millisecond precision while PostgreSQL keeps microseconds. The cursor therefore named a
moment just before that row, and the rows the next page should have started with, written earlier in
the same millisecond, were on no page at all. Anything that walked the trail page by page could miss
them without any sign of it. The cursor now carries the row's full timestamp. A cursor issued before
this change still reads.

### The New chat shortcut works on a Russian or Greek keyboard layout

Settings lists New chat as Shift+N, and the app matched the character the keystroke wrote. A layout
that writes another script has no key that writes an N: Shift and the N key write "Т" on Russian and
"Ν" on Greek, so the shortcut never fired there. When the character is not ASCII, the app now reads
the physical key instead. A layout that writes Latin letters, such as Dvorak, still goes by the letter.

### Enter that confirms a typed character no longer saves a name, a rule or a wizard step

Japanese, Chinese and Korean are typed through an input method, where Enter confirms the character
being built. In three fields that Enter also acted: editing a coworker's name or title saved it with
the character still unconfirmed, the new-coworker wizard moved on to its next step, and a boundary
rule was saved into the policy in force. Those fields now wait for the character, the way the chat
composer already does, and an ordinary Enter works as before.

### A built-in coworker can be edited where the deployment's own Bot is on localhost

A coworker created as Built in is stored pointing at the managed Bot's address. Editing its name,
title, role or visibility sent that address back as though somebody had typed it, and the server
checks an endpoint it is sent the way it checks a person's. `scripts/start.sh` puts the managed Bot on
`http://localhost:4201/ag-ui`, which that check refuses unless private hosts are opened, so every edit
failed with "That address is inside this deployment's own network, so an agent may not live there."
The dialog now leaves a built-in coworker's address where it is stored. A coworker somebody hosts
still sends its own endpoint, as before.

### A long page's text is cut between characters, not through one

A navigation hands the Bot the first 6000 UTF-16 code units of the page's readable text. When that
limit fell between the two halves of an emoji, the Bot was handed text ending on half a character,
which reads as U+FFFD: a broken character that is not on the page. It now stops one code unit short
in that case, which is what a control's name and value in a page snapshot already did.

### Tool selection reads a skill choice the model wrapped in a code fence

Before a run, the deployment's model picks which of a Bot's skills the message needs, so a Bot holding
many tools is offered only the relevant ones. The request asks for bare JSON, but an endpoint that
ignores `response_format`, as Anthropic's OpenAI-compatible one does, lets the model fence the object
or lead with a sentence. Every such answer read as no answer, so the Bot was offered every tool it
holds and the audit row said `unavailable`. The object is now read out of the answer, the way the
router already reads its own. A bare JSON answer is read as before.

### A long message reaches the coworker it is for, and is recorded

A message over 10,000 characters, such as a pasted email thread or log, was refused by the router
since it started capping the text it reads. The home composer carries on past a routing that fails,
so the message went to the default coworker rather than the one it is for, and a coworker chosen with
`@` or from the To: field started with no `channel.routed` row. The app now asks the router about the
message's opening, and the whole message still goes to the coworker. Shorter messages route as
before.

### Removing somebody is recorded even when retiring what they owned fails

Removing somebody denies their access and ends their sessions, then retires the credentials and
brokered connections they had granted this deployment. When that second half failed — a vault or
Composio not answering — the removal was already committed but nothing was written to the audit trail,
and removing them a second time reported success without retrying it, leaving those connections
standing. The removal is now recorded as soon as it takes effect, and removing somebody already
removed finishes the retirement that failed.

### Removing a connector takes its grants with it

A grant naming a connector's tool outlived the connector. Removing an app revoked every credential
and every brokered account and deleted the app itself, and left the grant rows behind, naming a
server that no longer existed. Nothing showed them: the page that reports grants a connector no
longer advertises reads them off the connector's own row, and there was none. Adding the same app
back — which mints the same id, and so the same tool names — put every action it had back on every
Bot that used to hold it, with nobody granting anything and no row in the trail saying a grant had
been made. An app's grants are now removed in the same step as the app, the removal records which
grants it released and from which Bots, and a migration drops the grants earlier removals left
behind. Grants for other connectors, and skill grants, are untouched.

### A vendor that broke no longer reads as a refusal to a Bot running its own loop

When a Bot that calls tools back from its own process, such as the LangGraph Bots, called a tool
whose vendor failed, or hit a fault in this deployment, the answer began "Refused." like a boundary
holding. The conversation drew it as blocked and the model read it as not allowed, while the audit
trail recorded a failed call. Only a refusal is marked now. A vendor that broke reads "That tool could
not be called: …", the way it already did for a Bot running here, and a refusal reads as before.

### A Bot running its own loop is told a vendor's error is the vendor's

A vendor that says no by answering with an error, the way an MCP server refuses a call, reached a Bot
running here as "The vendor reported an error: …", and reached a Bot calling tools back from its own
process, such as the LangGraph Bots, as the bare sentence. Those Bots pass the answer on as they
receive it, so their model read something like Google's "The caller does not have permission" as an
ordinary result, and could tell the person they had no access rather than that the vendor had refused.
Both kinds of Bot are now told the same thing. A result that is not an error, and this deployment's
own refusals, read as before.

### A long Composio result or failure is cut between characters, not through an emoji

A Composio action's answer over 20,000 characters, and a failure sentence as long, were cut by UTF-16
code unit. When the cut landed inside an emoji or any other character outside the Basic Multilingual
Plane, the text handed to the model ended on half of it: a lone surrogate that JSON carries as a bare
`\ud83d` and UTF-8 turns into a replacement character. The cut now stops one unit short in that case,
the way the MCP and built-in transports' cuts already do. Anything that fits is untouched, and the
note saying the answer was cut reads as before.

## 0.0.12

### A deployment can broker its Bots into a few hundred apps through Composio

Composio holds a person's connections to a few hundred SaaS apps behind one account. A deployment
that sets `COMPOSIO_API_KEY` now has that broker: each person connects their own accounts, a Bot is
granted an app's tools the way it is granted any other, and every call is decided and recorded
through the gateway like the rest. Unset, there is nothing to connect, nothing to grant and no
Composio tool for a Bot to call, and the Plugins page says so under **More apps** rather than
pretending otherwise. See [docs/plugins/composio.md](docs/plugins/composio.md).

### A skill's grants are removed when it is uninstalled

Uninstalling a skill deleted the skill but left its tool grants, which are keyed by its slug. A new
skill created under the same slug then inherited them, and was offered on the Bots the old skill had
been granted to with no grant ever made for it. Uninstalling now removes a skill's grants along with
it, in one transaction, and an upgrade drops any grants already left orphaned this way.

### Malformed requests are refused instead of coerced, and a fail-open is closed

A pass across the write and query surface answers a malformed request with a 400 that names the bad
field, rather than coercing it, failing at the store, or letting it through: the plugin server and
tool-call endpoints, the admin people search and credential input, skill tools and grant ids, blank
route ids on routines, host-access, agents and channels, the routing text length, routine dispatch
and page-frame params, and the runtime env, tokens and model content the computer and supervisor
read. The app reads these responses more defensively too, degrading rather than throwing on a shape
it did not expect.

One of these closed a hole rather than tightening an edge: a skill installed with a non-string entry
in its `tools` list had that entry silently dropped, so the skill declared nothing and installed as a
success. It is refused now.

### Naming a conversation asks the endpoint OPENAI_BASE_URL names, not OpenAI

The job that names a conversation sent its request to api.openai.com whatever `OPENAI_BASE_URL` said,
while the Bots, the router and tool selection all used the configured endpoint. A deployment behind a
gateway, a proxy or a local model therefore sent its model key, and the opening of every
conversation, to OpenAI; OpenAI refused the key, so no conversation was ever named. The request now
goes to the same endpoint as every other model call. A deployment that never set `OPENAI_BASE_URL`
behaves as before.

### A Bot's question to a person survives a route that fails

Who "a person" is, is a seam a deployment fills in with its own on-call rota or duty desk. If that
route failed by throwing rather than by returning a refusal — a timeout, a 502, a name that does not
resolve — the error came straight back out of the tool, so the Bot's run ended with nothing said to
the person waiting, and no audit row recorded that the question had reached nobody. The Bot is now
told, in a sentence it can say, that nobody could be asked and that it must not claim otherwise, and
an `agent.escalation_failed` row goes down carrying what the route actually threw. Deployments using
the shipped in-conversation route are unaffected: it cannot fail.

### Resetting a Bot's computer while the Bot is acting signs it out

On a deployment with one shared computer, which is what the published image and the Helm chart run by
default, a reset takes about two seconds to close the browser before it deletes the profile. A Bot
action that arrived in that window started a new browser from the profile about to be deleted, so the
Bot stayed signed in to everything until that browser next closed, while the reset reported success
and the audit trail recorded the saved state as deleted. A Bot's browser is no longer reopened while
it is being closed: the action waits for the reset to finish and starts signed out. Computers the
supervisor makes per Bot were not affected.

### A long control name or value in a page snapshot is cut between characters

The computer's page snapshot keeps the first 200 UTF-16 code units of each control's accessible
name and value. When that limit fell between the two halves of an emoji, the Bot was handed text
ending on half a character, which reads as U+FFFD: a broken character that is not on the page, often
at the end of a message the Bot had just typed into a text box. The cut now stops one code unit
short in that case, the same rule tool results and relayed answers already follow.

### A Bot's shell can no longer read the deployment's keys from a neighbouring process

In the all-in-one image the API and the browser ran under one account, and a Bot's shell — a child
of the browser — could read a same-account process's environment through `/proc`, whatever its own
environment had been scrubbed to. One allowed `computer_run_command` returned `KEY_ENCRYPTION_KEY`,
the session-signing secret and the database password, none of it on the audit trail. The API and its
migrations now run as their own account, so the kernel refuses that read; the browser is handed only
the variables it needs, so its own environment carries none of those keys; and the files under
`/run/s6/container_environment` are closed to the shell. A deployment that runs each Bot in its own
sandboxed computer, as the documentation asks for, was never exposed to this.

## 0.0.11

### The LlamaIndex Bot answers with the model the setup screen chose

The LlamaIndex Bot built an OpenAI client from `BOT_MODEL` and ignored `BOT_PROVIDER`, so it only
worked with an OpenAI model name sent to OpenAI. Picked with an Anthropic key, every run failed with
`Unknown model 'claude-sonnet-4-5'`; picked with an OpenAI-compatible endpoint, every run failed
with `Unknown model` for that endpoint's model, and an OpenAI model name went to api.openai.com
instead of the address given, because the client read `OPENAI_API_BASE` and not the
`OPENAI_BASE_URL` Compose passes. It now reaches the model through LiteLLM as `provider/model`, the
way the Agno Bot does, so all three choices answer. A model LiteLLM does not know is treated as able
to call tools, which the AG-UI workflow requires, and parameters a model does not accept, such as
the temperature LlamaIndex sends to a reasoning model, are dropped rather than refused.

### The Audit page says "not enforced" only under a dry-run refusal that went ahead

On a deployment in `dry-run`, the Audit page printed "dry-run: recorded, not enforced" under every
allowed action, because an allowed action is always carried out, and under a tool call content
inspection had refused, because that row copied `carriedOut: true` from the policy step before the
call was stopped. The line now appears only on a row the policy refused and dry-run let through,
which is the one case it describes. A tool call refused for carrying credential material is now
recorded with `carriedOut: false` in every mode. Rows already written keep their old value, and the
page reads them correctly either way.

### The Routines page says when nothing is there to run them

A routine needs a second process to fire it, and a deployment that never started one looked exactly
like a deployment that had: the routine was stored, its schedule was computed, and the page showed it
waiting with a next run time, right up until nobody's standup notes arrived. Every sweep now records
that it happened, and the page reads that record. Somebody with standing routines and nothing
sweeping is told so — that no worker has ever checked in, or when the last one did — instead of
being shown a page that looks correct. The window is the fifteen minutes a routine's own schedule
already has as its floor, so a gap longer than that is one no routine could have wanted.

### A long tool result or relayed answer is cut between characters, not through an emoji

A tool result over 20,000 characters, and a Bot's answer over 12,000 relayed back through a handoff,
were cut by UTF-16 code unit. When the cut landed inside an emoji or any other character outside the
Basic Multilingual Plane, the text handed to the model ended on half of it: a lone surrogate that
JSON carries as a bare `\ud83d` and UTF-8 turns into a replacement character. The cut now stops one
unit short in that case, the way an attached text file's already did. Anything that fits is
untouched, and the note saying the result was cut reads as before.

### A boundary rule can ask what started a run, not only whose authority it carries

A routine's turn goes through exactly the path a person's chat turn does, as the routine's owner:
their grants, their connections, their thread. That is the right design, and it is also why
`actor.id` cannot tell a scheduled run at three in the morning from the same person typing. The
trail already drew that distinction — `AuditInitiator` is signed into the run assertion and written
onto the row, so an investigator can see a routine caused something. A rule could not ask the same
question.

The policy context now carries `initiator`, with the kind and id the trail already records, so this
is writable:

```
deny: initiator.kind == "routine" && intent == "run_command"
```

A deployment happy for a Bot to run a shell while somebody watches, and not happy for it to do so
unattended, can now say so. The id is there too, so a single routine can be named rather than
scheduled runs as a class. `handoff` is its own kind, for a Bot that hands work to another Bot.

**Nothing is refused that was not refused before.** The field is neutral — `{kind: "person", id: ""}`
— everywhere a person is driving, which is every path that does not carry an initiator today,
including every action on a Bot's computer: those are driven by the browser, so they really are
somebody's session. It is required rather than optional for the reason #115 exists: cel-js throws on
an unbound identifier and a throw fails closed, so a field that were sometimes absent would turn one
rule about routines into a deployment that refused every ordinary click.

Replaying a rule against history reads the initiator off the row when it is there and treats a row
that predates the field, or carries a shape this version does not recognise, as a person.

### The Python LangGraph Bot tells its model why the deployment refused a tool call

When the deployment would not run a tool call from the Python LangGraph Bot — a token it no longer
accepts, one issued to another Bot, or a malformed call — it answered with the status and a reason
under `error`, and the Bot told its model only "Refused. Tool callback returned HTTP 403." The model
could say a call was refused but not why, and could not correct a call the deployment had named as
malformed. The reason now follows the status, the way the TypeScript LangGraph Bot already passes it
on. A refusal with no readable reason reads exactly as before.

### A tool argument that starts with "Basic" or "Bearer" is no longer refused as a credential

Content inspection read any MCP tool argument whose first word was "basic" or "bearer", in any case,
as an authorization header. A Bot searching Drive for "Basic onboarding checklist", or posting
"Bearer of bad news" to a channel, was refused because its arguments "contain credential material".
Those words are now refused only when what follows them is shaped like a credential: base64 that
decodes to `user:password` after `Basic`, and a token of at least 16 characters with a digit,
punctuation or mixed case after `Bearer`. A shorter bearer token, or a Basic value that does not
decode to `user:password`, is no longer caught by this pattern; the same value under an
`authorization` field is still refused by name.

## 0.0.10

### The LangGraph Bot says a refused tool call was refused, not that it found nothing

When the deployment would not run a tool call from the LangGraph Bot — a token it no longer accepts,
or one issued to another Bot — it answered 401 or 403 with a reason and no result, and the Bot told
its model "The tool returned nothing." The model then told the person nothing was found. The Bot now
tells its model the call was refused, with the status and the deployment's reason, the way the
Python LangGraph Bot already does, and the transcript draws it as a refusal. A tool that answered is
passed on exactly as before.

### Revoking a grant with a blank ref or Bot is refused instead of reported as done

`DELETE /api/plugins/grants` checked its query params with truthiness, and a query param is
always a string: `?ref=%20%20` is truthy, so it skipped the 400, deleted zero rows by exact
match, still wrote a `plugin_revoked` audit row naming whitespace, and answered `ok:true`. The
`POST` twin already required trimmed non-empty strings. `DELETE` requires the same now and acts
on the trimmed values, so a blank ref or Bot is a 400 with the same message, no delete, and no
audit row.

### The Bot in the box and the LangGraph Bot read a message that has a file attached

A message with a file attached reached both Bots as `[object Object],[object Object]`, in place of
what the person typed and the file both: they read a message as a string, and one carrying a file is
a list of parts. Each part now reaches the model as what it is — the words, the text of an attached
file, an attached image — and a part neither can read is named rather than dropped.

### A fractional or out-of-range computer setting takes the fallback instead of breaking the boot

`numberFromEnv` accepted anything `Number` called finite and positive, so `PORT=80.5` bound
nothing usable, `PORT=99999` misbound at boot, a fractional timeout fired before any action could
finish, and `COMPUTER_MAX_BROWSERS=2.5` reached eviction math as a fraction — each reading as a
broken computer rather than a mistaken variable. Every reader is a port, a timeout, or a count,
so only whole numbers on sight are values now and anything else takes the documented fallback;
the port additionally keeps its 1–65535 range, the way the supervisor's own port parser already
does. Zero semantics are unchanged: `COMPUTER_BROWSER_IDLE_MS=0` still keeps browsers resident.

### A malformed page size is refused instead of silently coerced

`GET /channels` and `GET /api/admin/people` read `?limit=` with `Number.parseInt`, which
coerces: `?limit=12abc` arrived as 12, `?limit=3.9` as 3, and each answered 200 with a silently
wrong page. Both now share one strict parser with the audit list's rule: absent or blank leaves
the store default alone, a run of digits is clamped into range against the same ceiling the store
enforces, and anything else is a 400 naming the parameter, before the database is reached.

### A skill written with a non-string slug or summary is refused instead of failing the insert

`POST /api/plugins/skills` checked presence with truthiness and then ran the slug regex, which
coerces: `{"slug":123}` tested the string `"123"` and passed validation, and `{"summary":{}}` had
no check at all. Both reached the store, where the insert threw an uncaught error — a 500 for a
caller error. A slug, a title and instructions must be non-empty strings now, the slug pattern is
tested only after that, and a summary must be absent or a string; anything else is a 400 naming
the field, before any refusal check, store write, or audit row.

### More endpoints refuse a malformed request instead of coercing it or failing open

The same treatment reached the rest of the write and query surface: the agent tool-call endpoint's
name and arguments, the policy dry-run and audit-event list limits, a component's publication flag,
the sandboxed-component fields, and a catalogue entry are each checked and answered with a 400 that
names the bad field before the store is touched. The four hand-driven computer gestures — click,
type, key and scroll — validate their own payloads the same way, so a click with no coordinates or a
key with no key is refused rather than sent to the computer as a no-op.

One of these closed a hole rather than tightening an edge. A component's list of decision functions
was filtered to the strings in it, so `{"functions":[123,null,{}]}` became an empty list, the
permission check ran over nothing, and the answer came back `allowed` for functions the caller had in
fact named. The verdict is about the functions named now, or a 400; an absent list still means none.

### Generated interfaces, tables and forms

Generative UI is enabled by default; set `OPENBOT_GENERATIVE_UI=false` or `0` to disable it.
Bots can render A2UI interfaces, compare records in sortable tables, and collect related answers in
a form that waits for submission. LangGraph receives the component schemas needed to draw these
interfaces correctly.

The playground rejects invalid JSON before saving or publishing, confirms successful saves, and
shows published custom components in the administrator's gallery.

### A Bot's computer is rebuilt when it holds a token the deployment has stopped using

A computer checks every caller against the `COMPUTER_TOKEN` it was created with, and holds that one
for the life of the container. The shell mints the generated secrets once per deployment and does
not rotate them, precisely because a computer outlives a restart, so ordinarily there is nothing
here to go wrong. Setting a machine up again from nothing is the occasion where the token really
does change: the credential store is emptied, a new one is minted, compose rebuilds everything it
owns with it, and the computers, which the supervisor makes rather than compose, survive holding the
old one.

Everything then refuses, and nothing says why. The gateway allows the action and the trail records it
as carried out, the computer answers 401, and the screen says "Not authorised" while naming no token
and no container. Measured on a first run of v0.0.9 against a computer made by the install before it,
five days earlier: every page the Bot tried to open, and the live screen beside it, failed that way.

The supervisor now replaces a computer whose token is not the one it is handing out, the same way it
already replaces one built from an older image, keeping the profile and workspace volumes so the Bot
comes back with its logins and its files. A deployment that sets no token is left alone, because a
computer with no door on it is a choice the environment made rather than a mismatch to act on.

## 0.0.9

### The People screen keeps a person's last sign-in when their sessions go away

`Last signed in` was `max(sessions.created_at)`, so it disappeared whenever the session rows behind
it did: on sign-out, on expiry, and when an administrator removed somebody. Restoring them did not
bring it back, and the person moved to the bottom of the list as somebody who had never signed in.
The moment of each sign-in is now recorded on the person, so the answer survives all three, and a
removed person's row shows when they were last here instead of leaving it out. Existing deployments
are backfilled from whatever sessions they still hold.

### A message can carry files

Pick them, drag them onto the composer or paste them in: up to eight files on one message, images up
to 8 MiB and text files up to 1 MiB, in the four image formats a model reads (PNG, JPEG, GIF, WebP)
and four text ones (plain text, Markdown, CSV and JSON). A file is uploaded as it is staged rather
than when the message is sent, so the send is immediate and a send that fails keeps what was
attached to it, instead of asking somebody to find eight files again. The bytes live in the
deployment's own database and are served back from the app's own origin, which is also why the type
is decided by reading the file rather than by believing what the browser called it: something that
claims to be text and is not UTF-8 is refused rather than stored and served as accepted text on the
client's word.

What reaches the model is bounded separately from what may be uploaded, because the two limits pay
for different things. An image goes whole. A text file is read up to 120,000 characters, roughly
30,000 tokens, which is one attachment's share of a window that also holds the conversation and up
to seven other files, and the part sent says where it was cut so the model is not left answering
about a file it read only part of. A megabyte of text is therefore stored whole and read as its
first eighth or so, and the person who attached it is not yet told that.

### Unsent attachments have to be swept, or somebody who stages 32 can attach nothing again

A file is stored when it is picked, not when it is sent, so every abandoned draft leaves bytes
behind and nothing in the image reclaims them. The Helm chart runs the sweep hourly and deletes
unsent files older than a day. Any other deployment has to run it:
`bun scripts/cull-staged-attachments.ts` from `/app/server`, one pass then exit, with the retention
window as its one optional argument. Unlike the routines sweep beside it, it needs only
`DATABASE_URL`, so an external cron can run it with one variable set.

This is not only about growth. A person may hold 32 unsent files across all their channels, which is
what bounds a client that ignores the eight-per-message cap, and the refusal on the 33rd tells them
anything still unsent is cleared within a day. That sentence is a promise made on the sweep's
behalf: where nothing runs it, the files are never cleared and anybody who reaches 32 can attach
nothing, in any channel, from then on. At 8 MiB a file, 32 staged files per person is the 256 MiB
to size storage against.

### Fresh desktop installs pin the latest published deployment

The desktop app resolves GitHub's latest published release on first setup and downloads that exact
tag's source and image manifest. It records the version after both downloads finish and reuses it
on subsequent starts, so new installs no longer stay tied to the app's old v0.0.8 default.

### The Bot computer refuses a malformed scroll or live input before the browser sees it

A non-finite wheel delta travelled into Playwright and came back as a 502 that read as a broken
computer, and any JSON object on the live-screen socket fell through to `Input.insertText` or
forwarded wrong-typed coordinates to CDP. Scroll deltas must be finite numbers now, and live
input must match its mouse, wheel, key, or text shape; anything else is a 400 naming the field.

### A non-string plugin grant or tool call is refused before it reaches the store

`POST /api/plugins/grants` and `POST /api/plugins/call` checked presence, not shape, so a JSON
number, object, or whitespace string passed and failed inside the store as a 500. Refs and Bot
ids must be non-empty strings now, and anything else is a 400 naming what is required.

### A fractional or infinite snapshot id is refused as malformed, not stale

A `snapshotId` of `1.5` or `Infinity` passed the acting routes and never matched the stored
integer, so the answer was a 409 stale snapshot and the caller retried a request that was
malformed. Non-integer ids are refused with a 400 naming the ref and its snapshot before any
decision or audit row.

### A `DATABASE_URL` with a port of zero is refused at start-up

`postgres://…:0/…` parsed and booted, and every query then failed against a port nothing listens
on. Ports outside 1-65535 are refused with a sentence naming `DATABASE_URL` before a socket is
ever opened.

### Setup installs the container engine, instead of telling somebody to go and get one

Setup ended at "Install Podman Desktop or Docker Desktop first" on any machine that had neither,
which is every machine this app is for: the step existed with nothing behind it, so the whole install
stopped at a download page. It installs one now, and a Compose with it, because Podman ships no
Compose implementation and a machine with a freshly installed Podman still cannot raise the stack.
Both are pinned to the digest of the release they were tested against and refused if it does not
match, because these are files this app then executes. Only what is missing is added: an engine
somebody already has is theirs, and a Compose that already answers is left alone. Windows installs
unattended; macOS and Linux each raise the platform's own authorization prompt, which is not
something to route around. The two plan sign-ins set the engine up as well, since they run in a
container themselves and previously named an obstacle with no way past it. Every engine command names
a resolved path rather than trusting the PATH this process was started with, so an engine installed a
minute ago can be used by the run that installed it.

### Setup ends with a question the Bot has to answer

Every step before the last one proves that something started, which is not the same as proving the
answers work. A refused key, a lapsed plan or a model the account cannot use each give a stack that
comes up clean and a Bot that cannot answer, and handing over at that point means somebody finds out
later, inside the product, with no idea which of their answers caused it. Setup now ends on a
question with one checkable answer and waits for it. A run that produces no text is a failure here
rather than an empty answer, because the framework catches its own 401 and logs it, leaving the whole
of a refusal in the container's log and nowhere else. The sentence on screen is OpenBot's own and
names the choice to change, with the harness's log behind a disclosure for the developer half.

### A subscription picks the Bot that can spend it

A plan is not a key, and only one Bot speaks each vendor's subscription. Signing in to a Claude plan
and keeping the default Bot gave a stack that came up clean and a Bot whose log read "Missing
credentials. Please pass an `api_key`", after two screens the person had answered correctly and with
no way to know which answer to change. A plan now re-points the Bot, and the model screen says which
Bot that will be while there is still a screen to say it on. A signed-in ChatGPT plan gets the Codex
model, because a plan token is a bearer for one address that langchain-openai pins on purpose and
cannot be reached by pointing `OPENAI_BASE_URL` at it. The vendor's own token store is kept beside
the `.env` as an owner-only file and mounted into the harness, so the renewals the provider makes
outlast the container: the access token on its own expires within the hour and nothing can renew it,
which would give a Bot that works in the morning and fails after lunch. The window also has an Edit
menu now, so the shortcut works on the screen whose own instruction is "paste the code it shows you";
macOS routes the clipboard through the menu bar, and a window without one has no Paste.

### Signing in to CopilotKit from the window works

The sign-in that creates a key for somebody had never been run end to end, and it failed four times
in a row, each time silently or with a message that named nothing. The session is called `cliToken`,
not `token`, so the first exchange failed with "error decoding response body" and no way to tell
which field or which endpoint; a failure carries the response now, masked, because the one that
diagnosed this also carried a live session token. Project ids are numbers, and requiring a string
dropped every project, so the screen told somebody with ten of them that the account had none: an
empty list and an unreadable one are told apart now, because one of them is a lie a person cannot
argue with. The keys endpoint declares `project_id` as a number with no coercion, so the string "7"
came back as a validation error on the last step of the flow. And the project tiles drew as blank
white rectangles, because the tile rule overrode the background to white and not the colour, asking
somebody to choose between six empty boxes. The sign-in address is kept on screen the way the plan
sign-ins keep theirs, for the machine whose browser is not the one in front of the person.

### An endpoint that needs no key can be connected

The compatible row names Ollama and vLLM in its own summary and then refused to continue without an
API key. Neither has one, so the two examples the screen offers by name were the two it would not
accept, and the way out was to invent a key and hope the endpoint ignored it. An address and a model
name are what that row needs. Both bundled Bots refused to start without `OPENAI_API_KEY` as well, so
fixing the screen alone would have given two dead containers complaining about a key that person's
server does not have: a base URL is a model and its key belongs to it, so a key is now required only
when nothing else names the endpoint, and plain OpenAI still refuses without one. Because a
deployment pulls the image the release pinned, and an image published before the Bots learned this
still refuses, a placeholder string is sent to an endpoint that reads no key. Ollama, vLLM, LM Studio
and llama.cpp all ignore the value. It is written in plain sight rather than put in the machine's
credential store, because it is not a credential, and a key somebody actually typed is used
unchanged. The model name reaches the bundled Bot too, which reads `AGENT_BOT_MODEL` and had been
left on a pin chosen for OpenAI's own catalogue.

### A model name no longer outlives the answer that chose it

The compatible row is the only one that names a model, and switching away from it kept the name.
Answering with an OpenAI key after trying a local endpoint left `BOT_MODEL=local-model`, so the Bot
asked OpenAI for a model only that person's own server has, and the last screen said "That account
cannot use the model that was chosen" about a model this run never chose. The name is removed rather
than emptied, so the compose default applies, and taken out of the file as well, because the writer
keeps the lines it did not write and that is what let it survive.

### Credentials go to the machine's own credential store, not the `.env`

The `.env` is a settings file, and a settings file is something somebody opens, reads out to support
or pastes into a chat. A model key, a plan token and the tokens these services prove themselves to
each other with are not settings. They go to the login Keychain on macOS, to DPAPI on Windows
encrypted to the signed-in user, and on Linux to an owner-only file, which is said out loud rather
than dressed up: no desktop Linux install can be assumed to be running a Secret Service daemon, and
refusing to save a credential because gnome-keyring is missing would fail more people than it
protects. The value never goes on a command line on any of them, since ps is readable by every
process the person runs. macOS goes through the Keychain itself rather than the `security` command,
whose password prompt truncates at 128 bytes with no error and an exit status of zero: an OpenAI
project key is 164 characters, so every one of them was stored cut short and read back cut short on
the next run, while the run that saved it worked fine. From the store the credentials reach the
containers and the host processes as environment, which compose resolves before it reads the `.env`,
so a secret arrives at exactly the services that declare it and is written down nowhere. What an
earlier version already wrote in plaintext is moved and then purged, or the change would have bought
nothing for anybody who already had OpenBot.

### The credential store is asked once per run, not once per screen

Four Keychain dialogs every time the setup screen mounted, each needing a click before the window
would go on, and four more for navigating between setup and OpenBot. macOS authorizes every
individual read of a stored password unless the application is signed with an identity the item's ACL
already trusts; a development build is re-signed on every compile, so its ACL never matches, and the
wizard reads four secrets to arrive filled in. The store is asked once per name per process now and
the answer is held in memory, absence included, or a machine with nothing stored is asked on every
mount for something that was never there. Writes go through the same memory and forgetting clears it,
so the two cannot disagree. This does not remove the prompts on a first run, and nothing in this
process can: that decision belongs to the operating system and to the signature.

### Stop stops the Bot that was picked, and the next Start no longer refuses because of it

Compose only acts on a profiled service when the profile is named, so Stop left the one container the
person actually chose running on their laptop after they had stopped the app, still holding its port.
The next Start then refused, saying something was already listening on 4206, about a container
OpenBot itself had started, which the person never saw and could not find, and there was no way
forward from that screen. A port this deployment already publishes is not a stranger on the port, so
the check reclaims our own and keeps its teeth for somebody else's.

### Stop stops the host processes on Windows

Measured on Windows Server 2022: Stop took the containers down, reported success, and left the server
answering on 3001, the routines worker up, and both halves of the app answering on 3010. Only the
containers had gone. The handles a window holds cover what that window started and die with it, so a
window stopping a stack an earlier one started held nothing, and the Windows arm returned success
with a comment saying the host processes end with the session. They do not. The pids are written
beside the logs when the processes start and Stop reads them, ending each process together with its
children, since `bun run serve` starts the real server as a grandchild. A sweep of the ports this
deployment publishes stays as a second pass for a stack whose pid file is gone. Separately, a
byte-order mark in front of `package.json`, which `Set-Content -Encoding UTF8` writes freely, made
the manifest unreadable and was reported as "the deployment is older than this version of OpenBot",
sending somebody looking for a newer installer over three bytes.

### The installed app is served without a development server

"Show OpenBot" did nothing on a machine where the stack was up. The window said OpenBot was running,
the button was there, and clicking it had no effect at all. The app host process was dead: it was
started through `vite preview` under `bun --bun`, and Vite's proxy calls `socket.destroySoon()` when
an upstream response ends, which bun's sockets do not implement, so the process died with a TypeError
on the first call the app made. It served its page, exited, and nothing listened on 3010 from then
on, while the shell went on reporting a stack that was up, because the containers were. The app is
served by a small server of its own now: a directory and one forwarded prefix, which is all an
install needs, with no Node and no Vite at runtime. The websocket upgrade the live screen needs is
forwarded rather than answered with HTML, a miss under `/assets` is a 404 rather than the page, and
paths are confined to the directory, since the deployment's `.env` sits two levels above it. The
button also shows what it was told: the call behind it already answered "OpenBot is not answering on
port 3010 yet, so there is nothing to show", and the click handler threw that sentence away, which is
why a dead process looked like a dead button.

### A conversation whose history this deployment cannot reach says so

Clicking a conversation in the rail drew the coworker's name and then nothing at all. The rail comes
from OpenBot's own database, so a channel is listed whatever the history store says, while the
messages live in the Intelligence project: pointing a deployment at a different project leaves the
platform answering `THREAD_NOT_FOUND`. That 404 is deliberately read as "no history" and has to stay
that way, because a thread id is minted before the thread exists, so a brand-new conversation 404s as
its normal opening move, and widening it would tell somebody their conversation was gone and invite
them to start it over. The two are told apart by `lastMessageAt`, which is set only once something
has been said: a conversation with none is genuinely new and silence is correct, while one that has
been spoken in and comes back empty has a history this deployment cannot reach. That one now says so,
in the notice slot beside the existing explanations for a deleted coworker and for turns that could
not be parsed.

### `bun run dev` no longer starts a routines worker that cannot start

`bun run dev` fanned out across every workspace, and one of them is the routines worker. That worker
is handed `DATABASE_URL`, `SERVER_INTERNAL_URL` and `WORKER_SHARED_SECRET` by `scripts/start.sh` and
by nothing else, so the copy this command started read none of them and threw at boot on every run,
printing a stack trace in between the app's output and the server's. It has never started
successfully. The command now starts the app and the server, which is what `README.md` and
`docs/development.md` already say it does. Routines are unaffected: `scripts/start.sh` starts the
worker exactly as before, and on Kubernetes the CronJob does.

### Double-clicking works while a person is driving a Bot's browser

A double click was sent to the Bot's browser as two separate first clicks, because every press said
it was the first one. Chrome fires `dblclick` on the page only when the second press says it is the
second, so the page never saw one at all and `event.detail` was always 1. Opening a row in a table,
expanding a node in a tree and double-clicking a word to select it were all things a person holding
the wheel simply could not do, with nothing on screen to say why — the clicks landed, they just each
counted as the first. The count the person's own browser worked out is now the one that is sent, so a
double click is a double click and a single one is unchanged.

### Pressing Enter works while a person is driving a Bot's browser

Taking the wheel of a Bot's browser is mostly for the sign-in it cannot do itself, and Enter is how a
sign-in ends. Every keystroke reached the page, and Enter reached it as a key press that produces no
character — which Chrome delivers to the page's own listeners and then does nothing further with. So
the form did not submit, a new line in a text box did not start, and a button somebody had tabbed to
was not pressed, while anything on the page listening for the key saw it arrive. There was nothing on
screen to explain it: the keystroke was not refused, it simply had no effect, and the way out was to
click the submit button instead. Enter now carries the carriage return a keyboard sends, which is
what makes Chrome carry out what the key means. Measured against Chromium 151: every other editing
key — Backspace, Delete, Tab, Home, End and the arrows — already did what it meant and is unchanged,
and a single-line field still holds exactly what was typed into it.

### A half-ticked box is no longer described to a Bot as ticked

The snapshot a Bot reads before it acts on a page says whether each box is ticked, and Playwright
writes that as `[checked]` for one that is and `[checked=mixed]` for one that is neither — which is
what the "select all" above a partly-ticked list carries. The parser treated any value other than
the string `false` as ticked, and `mixed` is one, so a half-ticked box was reported as done. A Bot
asked to select everything read it as already selected, clicked nothing, and said the rows were
chosen when most of them were not. `mixed` is now reported as not ticked, which is both the true
half of a yes-or-no answer and the one that gets the right action: clicking a half-ticked box ticks
it. An ordinary tick and an ordinary empty box are unchanged.

### A Bot cannot end its turn by asking a person nothing

`ask_person` is how a Bot stops and puts something to a person instead of guessing, and a call with
no question in it was already meant to come back as a sentence telling it to say what it needs. That
only happened when the field was missing altogether. A question that was present and empty was
carried out: the Bot was told its question had been put to somebody, its turn ended there, and the
trail took an escalation row with nothing in its question — the row an administrator counts these by,
saying a person was asked something that was never said. On a deployment whose escalation route is a
duty desk rather than the person already in the conversation, it is a page to somebody with no
question on it. A blank question is now refused with the sentence that was already written for it,
and a question typed with room around it is recorded as the question rather than as the spacing.

### A routine scheduled for Sunday says Sundays, whichever number it was written with

Crontab has always let Sunday be either 0 or 7, the scheduler here takes both, and a routine written
with 7 is stored and fires on Sunday like any other. Only the 0 spelling was recognised by the
sentence the Routines page draws and the Bot reads back, so a working weekend routine appeared on
that page as `0 9 * * 7` while its neighbour said "Sundays at 09:00" — the same schedule, described
two ways, with the raw one looking like something had gone wrong. Both spellings now read as Sunday,
and a list that names the day under both of its numbers says it once.

### A tenant package's theme may carry a comment

A package's `theme.css` is checked at start-up against what it is allowed to define: the `:root` and
`.dark` blocks, the approved variables, no imports and no URLs. A CSS comment defines none of those
and was being read as though it did. One above the blocks — the line a hand-written stylesheet opens
with, saying whose brand it is and where the colours came from — was left over once the blocks were
set aside and refused as a second selector; one inside a block was split on the semicolons around it
and refused as a variable name, with the comment quoted back as the name it was not. Because the
package is read while the deployment starts, that was not a warning: the deployment did not come up,
over a comment, saying nothing about comments. Comments are now taken out before the file is read as
definitions, which also closes a comment wedged into the middle of `url(` as a way past the rule
above it.

### Test connection stops reading once it has seen the agent answer

The button that checks an agent before it is registered sends it a real run and reads what comes
back, needing only the opening of the stream to tell an AG-UI agent from a web server that happens to
be reachable. It was reading the whole reply first and applying that limit afterwards, so the check
took as long as the agent's run did. An agent that streams for more than fifteen seconds — a Bot
working through a document, a model answering slowly — was given up on mid-answer and reported as
`The agent started answering and the connection broke`, about a connection that had not broken and an
agent that had answered correctly in its first two events. It now reads the opening it needs, closes
the connection, and answers in the time the agent took to start rather than the time it took to
finish.

### A key pasted with a line break in it is now refused, instead of reported as an unreachable agent

The box that holds an agent's key takes whatever is pasted into it, and what comes off a clipboard is
not always what was on the screen: a long key copied out of a wrapped terminal line brings the wrap
with it, and a hyphen copied out of a document has often been turned into an en dash on the way.
Neither can be sent as an HTTP header — the runtime refuses the value outright — and neither was
being looked at. On Test connection that refusal surfaced as "This server could not reach that
address", with a suggestion about tunnels and firewalls, about an agent that was running perfectly
well and had never been dialled. Stored on the Bot it was quieter and worse: the form said saved, and
every turn that Bot took afterwards failed on a value nothing on screen said anything about. Both
places now check the value before accepting it and say which kind of character is in the way. The
character is named; the key never is.

### A deployment directory pasted with a stray space goes where it says

The desktop setup screen asks where OpenBot should live, enables Start once that box is not blank
after trimming, and then sent the untrimmed string — the same trap the API URL, the gateway URL, the
intelligence key and the model key were taken out of, and this is the one of the five that is a
place on disk rather than a credential. A path copied with the space the selection picked up, or
with the newline a copied line carries, was used whole. A trailing space made a second directory
beside the one everything else means: the tray's Stop and the next launch both ask for the default
path, which has no space in it, so a person was left with a deployment nothing on screen could
reach. A leading space was worse, because a path starting with a space does not start with a
separator — it stopped being absolute, and the deployment was laid out relative to wherever the
window happened to be running from. The path is trimmed at both ends now. Spaces inside it are part
of a directory's name and are left alone.

### The desktop app notices a busy port whichever loopback holds it

The shell refuses to start when something already holds port 3001 or 3010, because otherwise the
readiness check that follows is answered by a server it never started: everything reads green and
none of it is yours. That readiness check asks both loopback addresses on purpose, since a process
binds whichever one its runtime resolved `localhost` to — Node picks `::1`, Bun picks `127.0.0.1` —
so an answer at either counts. The refusal in front of it asked only `127.0.0.1`, which meant a port
held on `::1` alone was reported free and the start went ahead into it. Both addresses are asked
now, so the two agree on what "in use" means and the person is told which port is taken and what
OpenBot wanted it for.

### A request for a secret no longer follows a Bot into tomorrow's conversations

An unanswered ask to take the wheel stops being shown after ten minutes, because control belongs to a
Bot's computer rather than to a conversation. The other prompt on that computer, the masked box a Bot
opens when it needs one value it must not be told, was never given the same treatment: it sat there
indefinitely, so every later conversation with that Bot was flagged as needing a person and showed a
request for a password, captioned with a label written for whoever asked half a day earlier. It now
expires on the same ten-minute window, and stops being answerable at the moment it stops being shown,
so a value typed into a box left open in an old tab is refused rather than sent to a page whose run
has ended. A request inside the window is unchanged, and a person actually holding the wheel is still
never timed out.

### `COMPUTER_BROWSER_IDLE_MS=0` now keeps browsers resident, as it says it does

Zero is the documented way to switch off the sweep that closes a Bot's browser after it has sat
untouched, and the sweep itself reads a timeout of zero as being switched off. The value never got
that far. It was read the way the cap on running browsers is, where zero would close every browser
the moment it opened and so has to be refused, and an operator who typed zero got the thirty-minute
default handed back instead. Their browsers went on being closed, which is a Bot signed out of a site
that only issues session cookies and a cold Chromium on its next turn. Zero is now kept for this one
setting. A blank variable, which is what an unset variable declared in a compose file arrives as, is
still not zero: it means "not set" and takes the default, as do a negative and anything that is not a
number.

### A flag or a family emoji in a channel preview is no longer cut in half

The one line a roster draws is cut to a cap, and the cut walked code points -- right for a plain
emoji, wrong for every emoji built out of more than one. A flag is two regional indicators, a family
is three people joined by zero-width joiners, a thumbs-up with a skin tone is the thumb plus a
modifier, and a keycap is a digit plus a variation selector plus an enclosing mark. Landing the cut
inside any of those left a boxed letter, a dangling joiner or a bare digit in the sidebar, in the
generated channel title, and in the excerpt the titler is shown. The cut is now taken between
grapheme clusters, so what a person sees as one character is kept or dropped whole. Plain text is
cut in exactly the same place as before.

### A scroll with an unusable `deltaY` is refused, rather than scrolling some other distance

`POST /computers/:botId/scroll` and `POST /computers/:botId/human/scroll` accepted any JSON number
as `deltaY`, and `1e999` is a JSON number: it parses to `Infinity`, passes the `typeof` check, and is
turned back into `null` by the hop to the Bot's computer, which reads the field as absent and scrolls
its own default distance. The caller was answered 200 for a scroll it had not asked for. A `deltaY`
that is not a finite number now answers 400 and the page is not touched, the way the timeout on
`exec` and the coordinates behind a person's click already did.

### An MCP call carrying `x-api-key` is stopped the same as one carrying `api-key`

The check that keeps credentials out of MCP tool arguments compared each argument name against a
list, and `api-key` was on it while `x-api-key` was not -- so the spelling that is more obviously a
credential header was the one that went out. `x-` is the conventional prefix for a non-standard
header and says nothing about the value, so it is now dropped before the comparison. The same pass
adds the spellings of names already on the list that were missing from it: `passwd` and `pwd` for
`password`, `auth_token` and `bearer_token` and `session_token` for `token`, `api_secret` and
`secret_key` and `signing_key` for `secret`, and `ssh_key` for `private_key`. Nothing new counts as
a credential: an argument named `x_axis`, `token_count`, `max_tokens` or `secretary` is passed as
before.

### One command to stop what `start.sh` started

Stopping the local stack meant four commands read off the end of a successful start, and the one
easiest to miss was the one that mattered: a Bot's computer is made by the supervisor rather than by
compose, so `docker compose down` left a Chromium running per Bot. `bash scripts/stop.sh` stops the
app, the routine worker, the API server, the compose services and every Bot computer, in that order,
and is safe to rerun. It kills a port holder only once that process has identified itself as
OpenBot, so an unrelated process on 3010 is named and left alone rather than killed. Nothing is
deleted: the database, the Bots' files and their browser profiles are volumes. `--keep-computers`
leaves the browsers signed in.

### The trail says when an identity provider was added, not only when one was taken away

Whoever holds an identity provider decides who can sign in at all, and the audit trail recorded only
half of that. Removing one through the administration screen was written down; registering one was
not, because registration is the sign-in library's own endpoint and nothing this deployment owns ran
on the way through. The event type for it had been declared and never written. Removing a provider
through the library's endpoint rather than the screen was unrecorded for the same reason. Both are
now written where the deployment already stands in front of those routes to check that the person
asking is an administrator, so a provider appearing or disappearing names itself and whoever did it.

### Two workers on one machine can no longer fire the same routine twice

Every process that claims work from the shared queue named itself after its hostname, and the queue
tells two claimants apart by that name alone. Two processes on one machine therefore had the same
name, so the lease meant nothing between them: one whose lease had lapsed was still told the item was
its own, and both went on to dispatch it. A routine fired that way opens two runs and sends the same
scheduled message twice. Nothing stops two workers running on one machine — the worker binds no port,
and `scripts/start.sh` looks for a process it does not start the way `bun run dev` does. The name now
always carries a random suffix, so a second process is a different claimant. It also keeps the
hostname, so a stuck claim still traces back to the machine holding it, and a blank `HOSTNAME` is no
longer read as a name — which had made every replica in a deployment share one.

### The desktop app writes its `.env` readable only by its owner

The desktop `.env` holds `KEY_ENCRYPTION_KEY` and every minted token, and those are now long-lived:
the first start writes them and every later start reads them back. It was created at the default
umask (`0644`), so on a shared macOS or Linux machine another local user could read the vault key off
disk. The file is now narrowed to `0600` after it is written. Windows has no equivalent mode and its
single-user desktop profile is already the boundary, so the change is Unix-only.

### The desktop app stops adding a banner to `.env` on every start

`env::write` keeps the lines it did not write, and its own header comment is one of them, so each
start preserved the previous banner and appended another. A deployment started fifty times had fifty
copies of "Written by OpenBot Desktop" and fifty blank lines stacked above its settings. The banner
is now recognised and replaced rather than kept, and comments somebody else put in the file are left
alone exactly as before.

### Starting the desktop app again keeps the secrets the first start generated

The shell generated a fresh set of secrets every time Start was pressed, including the
`KEY_ENCRYPTION_KEY` that encrypts the credential vault. The database survives a stop, so the second
session of an installed OpenBot met a vault it could no longer read: every stored credential failed
to decrypt, with an error that named an operation rather than a cause. It also handed the server a
`COMPUTER_TOKEN` that no computer created before the restart holds. The secrets an existing `.env`
already carries are now kept, and only generated when there is nothing usable to keep — a value
published in this repository does not count, and neither does a `KEY_ENCRYPTION_KEY` the server would
refuse to start on.

### The desktop app refuses a deployment download that writes outside its own directory

The shell fetches the release tarball and lays it out under the directory it manages. The check that
kept an entry inside that directory compared paths lexically -- `root.join(path).starts_with(root)`
-- and `Path::starts_with` matches components without resolving `..`, so `app/../../elsewhere`
started with the root and still landed outside it. An entry has to begin with a directory a
deployment wants, which `app` does, so the file filter did not stop it either. Every component of a
path inside the tree is now required to be an ordinary name, and the traversal is refused by name.

### A credential pasted with a stray space into the desktop setup screen now works

The setup screen enables its button on `value.trim() !== ""` and then sends the untrimmed string, so
a key copied from a provider's dashboard with the space the selection picked up arrived intact. The
model key was trimmed on the way into `.env`; the API URL, the gateway URL and the intelligence key
entered on the same screen were not, so Compose passed the space through, the provider rejected the
credential, and the failure the person saw named neither the space nor the field. All four are now
trimmed the same way.

### Example LangGraph and Mastra Bots no longer bind an ephemeral port on empty `PORT=`

An empty `PORT=` in compose or `.env` used to become `NaN` for those two example processes, so they listened on a random port while docs still named 4300/4400. They now use the same `listenPort` helper as `agent-bot`: empty is the documented default, and a prefix typo refuses to start.

### An empty app port is the default, not a random one

`APP_PORT=` and `SERVER_PORT=` in a compose file or leftover `.env` used to become `NaN` for the Vite
dev and preview servers, so the UI bound an ephemeral port while the proxy target was `http://localhost:`.
Both empty values now mean the documented defaults (3010 and 3001), and a non-numeric value refuses to start.

### The trail says what started a run, not only whose authority it had

A routine runs as the person who set it up, and a Bot handing work to another Bot runs as the person
who began the conversation. Both are correct, that is whose grants and whose connections are being
used, and both meant an action taken while somebody slept was written into the audit trail as though
they had taken it themselves. Telling the two apart meant correlating timestamps against
`routine_runs` by hand, and there was nothing at all to correlate a hop against.

Every audit row now also names what caused it: a person, a routine, another Bot handing work on, or
the deployment itself. It travels inside the signed run assertion, so a tool call, a hop, a Bot
stopping to ask its person and a stalled stream all say it, and a Bot cannot relabel its own run.
The Audit screen has a **Started by** column and a **Nobody watching** view that answers the
question directly. An unattended run is the one nobody is there to notice going
wrong, which is the reason it is worth being able to find.

The fourth of those exists so the column never overclaims. Two rows have no person behind them at
all: the boundary and isolation rows written at start-up, and the refusal written when a caller
cannot be identified at all. Those say the deployment, not a person, and they stay out of
**Nobody watching**, which asks what ran on somebody's authority rather than what the deployment did
by itself.

Nothing about existing rows changes. Every row already written, and every row a person's own click
writes from now on, reads as a person, because that is what it was.

### The live screen and live channel updates work again, and one request can no longer end the app

The app opened its two WebSockets against its own address, so they travelled through Vite's `/api`
proxy. Vite is run through bun, and under bun that proxy does not carry a WebSocket: neither the
Bot's screen nor live channel updates ever connected, and the browser retried in a loop. Worse, an
upgrade the server answered with an ordinary HTTP response — a 503 when a Bot's computer is not
running, which is exactly when somebody opens the screen — crashed the process that served the app,
taking the server and the worker with it in development. Where Vite serves the app — the dev server
and the desktop's `vite preview` — both sockets now address the server directly, so nothing upgrades
through the proxy and the proxy no longer offers to carry one. In production the server serves the
app itself and answers the upgrade on the same origin, so the sockets stay on the browser's own
host, which is what an ingress terminating TLS on 443 requires and a fixed server port would break.

## 0.0.8

### A desktop shell that installs OpenBot and then becomes it

One window, on macOS, Windows and Linux. From a machine with nothing on it, one click fetches the
deployment for this release, pins every image to the digest the release published, generates the
secrets that are OpenBot's to generate, raises the containers, applies the migrations, installs the
dependencies, starts the host processes, waits until both the API and the app answer, and then shows
OpenBot in the same window. It is not a launcher for a browser tab. Stop takes the stack down, closing
the window hides it to the tray, a second launch hands over the window that already exists, and
quitting stops what starting started. Windows is told what it needs before anything else runs: WSL,
its kernel, virtualisation and administrator rights are each named with the command that fixes them,
because none of them is something OpenBot can fix on somebody's behalf.

### A title or name that is only spaces is refused rather than stored

Sandboxed components, skills, custom servers and the component catalogue each accepted a title, slug
or id made entirely of whitespace, and stored it. What came back was a row nobody could identify and,
in the catalogue's case, entries that were empty strings. Each endpoint now refuses those the way it
refuses a missing field, and the catalogue drops empty entries instead of keeping them.

### A malformed socket message no longer takes the screen down

The live screen and the channel socket both assumed every payload they received was an object of the
shape they expected. Anything else threw inside the handler, which in a browser means the surface
stops updating with nothing on screen to say why. Both check the shape first and ignore what does not
match.

### The worker refuses a bad server URL when it starts, not when it first needs it

`SERVER_INTERNAL_URL` was read as a string and used as one. A value that was not an http or https URL
failed later, inside whichever call happened first, with an error about that call rather than about
the setting. The worker validates its environment up front now and normalises the URL, so a typo stops
it immediately and says which variable is wrong.

### A sandbox template that is not valid JSON is reported as a sandbox error

A malformed template surfaced as a raw parse error from whatever tried to read it. It is a
`SandboxError` now, which is what the caller already handles and what the surface already knows how to
show.

### A duration written in capitals is understood

`durationMs` accepted `30s` and refused `30S`. Units are read case-insensitively now.

### The supervisor refuses a `HostPort` that is not a port

The value went through a bare `parseInt`, so `80abc` became 80 and an out-of-range number was used as
given. Digits and range are checked, and anything else refuses to start rather than binding somewhere
nobody asked for.

### The audit endpoint refuses a bad date or limit instead of guessing

An unparseable `from` or `to`, or a `limit` that was not a whole number, was coerced and the query ran
against whatever came out. All three are parsed strictly now and a bad one answers 400.

### Chat content that does not parse is dropped rather than thrown

One malformed entry in a user message threw and took the whole message with it. The malformed part is
dropped and the rest is delivered.

### The example package is read by a path the host accepts

It was addressed by a URL pathname, which is not a path on Windows. It is read by a real path now.

### The app can be served from a built bundle, and listens on both loopbacks

The app's only start script was `dev`, which runs a Vite dev server. That meant `NODE_ENV=development`
on a freshly installed product: the SDK drew its developer inspector over the top, with hot reloading
and source maps behind it. There is a `serve` script now that builds once and serves the build. Both
it and `dev` hand Vite to Bun directly, because `node_modules/.bin/vite` begins `#!/usr/bin/env node`
and a machine with Bun and no Node exits 127 without saying why. Vite is also told to listen on `::`,
since Node resolves `localhost` to `::1` and Bun to `127.0.0.1`, so binding one of them left whoever
asked for the other looking at nothing.

### A person's Stop is recorded as a stop, not as a failed action

Pressing Stop mid-action aborts the request, and the gateway wrote that outcome beside the decision
row as a failure — the same `computer.action_failed` type it writes when a computer is unreachable or
times out. The row's message already said the action was stopped, but anything counting failures by
type, the natural way to watch for outages, read every Stop as one. A stop now writes its own type,
`computer.action_stopped`: the action did not happen and nothing broke. The audit page already groups
it with the other did-not-happen outcomes, and a policy dry-run skips it the way it skips a failure,
since both sit beside a decision row that is already scored.

### A malformed `DATABASE_URL` is refused without printing the password

`DATABASE_URL` is taken apart before it reaches Bun, and the string most likely to fail that parse is
one with a stray character in the password. The refusal for an unparseable value quoted the whole
string back to name the fault, which wrote the database password into the log line that reported it.
It now names the variable and the shape it expects, the way the other refusals beside it already do,
and never echoes the value.

### Wiping a computer is recorded even if clearing its stored state fails

Resetting a computer destroys the profile first and wrote the audit row last, after two Postgres
deletes. A connection reset, a failover or a statement timeout in either delete threw before the row
was written, so the most destructive button in the product could leave a wiped computer -- every
login gone, no undo -- with nothing on the trail to say who wiped it or when. The row is now written
as soon as the profile is gone, which is the point after which nothing can be put back. A failure in
either delete is still reported to the caller.

### Pressing Stop is recorded as a stop, not as a computer that is not running

The computer transport answered a Stop correctly only when it arrived before the request left. The
caller's signal is handed to `fetch` precisely so a Stop can also land mid-action, and a fetch
aborted that way rejects with an `AbortError`, which fell through to the message for a computer that
cannot be reached. The person was told their own click had failed because the assistant's computer
was not running, and the gateway wrote that sentence into the action's audit row as its failure --
so a deliberate stop read back as an outage. A genuinely unreachable computer and a timeout still
say what they said.

### A component the server refused is no longer drawn anyway

A sandboxed component asks the server at call time whether the Bot may still use it, and a refusal
is recorded so the drawing can be replaced with a card saying so. The renderer looked that refusal
up under `props.toolCall.id`, which is the shape a tool HANDLER is given; a renderer's props carry
the id flat, as `toolCallId`. The lookup key was therefore always undefined, the refusal was never
found, and the component rendered as though it had been allowed -- so revoking a component from a
Bot did not take effect on screen until the five-second grant poll caught up, and a failed decision
request showed nothing at all.

### A component whose name has a stray space is the same component

The catalogue announcement asked whether each component's `name`, `title`, `kind` and `description`
were more than whitespace, and then published the untrimmed strings. A `name` is a component's
identity -- it is what `syncCatalogue` compares against what is already published, what `decide` and
`listForAgent` look up, and what a grant names -- so a build shipping `" weatherPanel "` added a
second catalogue row beside `weatherPanel`: published, ungranted by anybody, and impossible to hold
a Bot back from under the name people use. The four fields are now stored as the strings the guard
approved.

### A password with a `%` in it says so, instead of failing as `URI error`

`DATABASE_URL` is taken apart before it reaches Bun, and each part is percent-decoded. A part
holding a `%` that starts no escape -- `postgres://openbot:100%pure@host:5432/openbot`, which a
generated password produces often enough -- is a string `new URL` accepts and `decodeURIComponent`
rejects, so the server stopped with `URIError: URI error` and named neither the variable nor the
part. It now refuses with the same kind of sentence as every other malformed address: which part is
wrong, and that a literal `%` must be written `%25`.

A correctly encoded password is unaffected.

### An empty Bot `PORT` is unset, so NaN never reaches Bun.serve

`PORT=` on `agent-bot` and `agent-langgraph` used to parse as `NaN` (`??` does not treat empty as absent) and `Bun.serve` bound an ephemeral port while compose still published 4200/4201. A prefix typo (`42o0`) started on 42. Empty now means the shipped default; anything that is not a whole port number refuses to start.

### The server connects to Postgres on Windows, and `localhost` is no longer a coin toss

Two separate faults, both of which stop a deployment reaching its own database and neither of which
says so.

The connection address went to Bun as a URL. Bun reads such a URL's path, the database name, as the
path of a unix socket, ignores the host and the port, and fails to open a socket Windows does not
have (oven-sh/bun#27713). The server could not reach Postgres there at all, while `psql` inside the
container and a plain TCP connection from the same machine both worked, which makes it look like a
network fault rather than a parsing one. The address is now passed in parts, and `DATABASE_URL` is
removed from the environment as it is read, because Bun prefers that variable to the parts it was
handed and would otherwise put the address straight back through the same parser. A URL with no host
or no database is now refused by name instead of connecting somewhere nobody chose.

Separately, Compose published its loopback ports on `127.0.0.1` only. `localhost` resolves to `::1`
and `127.0.0.1` in an order the platform decides, and a client handed `::1` first does not fall back
to the other, so the same configuration worked on one machine and failed on the next for a reason
nothing in the error mentions. Every loopback port is now published on both addresses. Both are
loopback, so nothing became reachable from another host.

### A bad `COMPUTER_MEMORY_BYTES` refuses to start the supervisor, instead of capping a computer at 512 bytes

`COMPUTER_MEMORY_BYTES=512m` used to parse as `512` via `parseInt`, which Docker accepts as a memory
cap Chromium cannot live in. Empty `COMPUTER_MEMORY_BYTES=` is still unset (no cap). A value that is
not a whole number of bytes now exits before any computer is created.

### An IPv6 address in `AGENT_ENDPOINT_ALLOWED_HOSTS` now matches however it is written

The endpoint check compares the list against the address as the URL parser spells it, compressed
and lower-case, while the list kept each IPv6 entry as the operator wrote it. `[0:0:0:0:0:0:0:1]:8443`
was therefore a line that silently never matched, the failure the list's other refusals exist to
prevent. Stripping the brackets on both sides also folded two different names into one, so naming
`[fd00::1:8443]`, an address, admitted `[fd00::1]:8443`, another address on a port, and the other way
round. Bracketed entries are now stored in the parser's spelling, with the port kept as written, and
compared with their brackets on; an entry the parser does not read as an address is refused at boot,
naming the entry, as a URL or a wildcard already was. Names and IPv4 entries are unaffected.

### A Bot's own decline is only recorded against a Bot the caller may reach

A Bot reports that it declined a request through the person's session, and the audit row says
`reportedBy: the Bot itself`. The route wrote that row for any agent id in the path, without asking
whether the caller could reach that Bot, so any signed-in person could put a decline, in any words,
against any coworker, one they cannot see included, and an administrator reading the trail would take
it for something the Bot said. The route now asks the store first, as every other route on a Bot
does, and answers not found for a Bot the caller cannot reach, writing nothing.

### The engine socket the supervisor is given can be pointed somewhere else

Compose mounted `/var/run/docker.sock` into the supervisor as a fixed path. That is correct for
Docker, and for Podman on macOS, where `podman machine` symlinks it to the rootless socket inside the
virtual machine. It is wrong for rootless Podman on Linux, where the path is either absent or, with
`podman-docker` installed, a symlink to `/run/podman/podman.sock`, the rootful socket, which is not
the one running. The supervisor held a dead socket and every attempt to give a Bot a computer failed
with a message about not reaching Docker.

The mount source is now `ENGINE_SOCKET`, defaulting to `/var/run/docker.sock`, so nothing changes
unless it is set. On rootless Podman on Linux, set it to `$XDG_RUNTIME_DIR/podman/podman.sock`.

### A Bot's computer is waited for properly on Podman, and the supervisor can reach the engine there

Two things stopped OpenBot running on Podman, which nothing had tried before.

The supervisor could not reach the engine at all: `The supervisor could not reach Docker`. The socket
is there and the mount is right, but Podman's virtual machine runs SELinux and labels the socket in a
way a container is not allowed to read. The supervisor now declares `label=disable`, which is what
that needs and which changes nothing on Docker.

Then every cold start of a computer raced the first request to it. Readiness was read off the image's
`HEALTHCHECK`, and Podman does not report one: its images are OCI-manifest, the OCI image config has
no healthcheck field, and the instruction is dropped both when Podman builds an image and when it
pulls one that has it. With no health to read, the supervisor fell back to accepting a container that
was merely running, and a running container is not a browser that is answering, so the first request
arrived at a port nothing was listening on and came back as a computer that is not running. The
supervisor now states the healthcheck when it creates a computer instead of inheriting it, so
readiness no longer depends on how the image was built. On Docker the behaviour is unchanged.

## 0.0.7

### The published service images are zstd rather than gzip

An image pull was already a compressed transfer, so this is not compression where there was none; it
is a better algorithm for the same job. `agent-computer` goes from 962 MB to 886 MB on the wire, and
zstd inflates several times faster, which on 2 GB of Chromium is worth more than the 8%. The saving
comes from recompressing the layers that arrived from somebody else's registry, where nearly all of
the bytes are, so the images no longer share layers with a gzip pull of the same base.

This applies to the five `ghcr.io/copilotkit/openbot-<service>` images and not to
`ghcr.io/copilotkit/openbot`. Reading a zstd layer needs a client that supports it, which Podman and
current containerd do; the single image is pulled by deployments running whatever they have, so it
stays gzip.

### A release publishes every service's image, not just the one

`ghcr.io/copilotkit/openbot` was the only image a release produced, so anything running the Compose
stack built `agent-computer`, the supervisor, both Bots and the migration image from source on
every machine. That needs a toolchain and it needs several minutes, most of them Chromium, and it
is the difference between a deployment and a laptop being able to start at all.

Each of those is now published beside it, at `ghcr.io/copilotkit/openbot-<service>`, carrying both
`linux/amd64` and `linux/arm64` so one reference works on a server and on an arm64 laptop. Every
image gets its own build provenance attestation, and `container-images.json` on the release pins a
digest for all of them rather than for one.

Nothing changes for a checkout: unset, `COMPUTER_IMAGE`, `SUPERVISOR_IMAGE`, `BOT_IMAGE`,
`LANGGRAPH_IMAGE` and `SERVER_IMAGE` name local tags and Compose builds them as before. Point them
at published digests and set `IMAGE_PULL_POLICY=missing` to pull instead. `docs/releasing.md` shows
reading the references out of `container-images.json`; `docs/configuration.md` lists the settings.

CI now builds those five Dockerfiles too. Nothing did before, because they are built by
`docker compose up --build`, which only the smoke journey runs and which cannot run in CI, so a
broken one surfaced during a release after the first image had already been pushed.

### A skill can be written in the conversation instead of retyped into a form

A skill is four fields and an instruction a Bot follows, and the instruction is the one that decides
whether the skill works. The only place to write it was a textarea on `/skills`, which meant having
the conversation, getting a good draft in the transcript, and then copying it out and retyping it.
Mostly nobody bothered, which is how a deployment runs for months with no skills in it.

The example package now ships a `skill-creator` skill, granted to `general-assistant`. A Bot holding
it is offered four tools for listing, reading and saving skills; every other Bot is offered none of
them. It interviews you about the skill you want, looks at what already exists before naming it,
rehearses it against one realistic request, and then saves it.

The save is a card, not something that happens quietly. It draws the command, the title, the declared
tools and the whole instruction, and writes nothing until a button is pressed. A skill appears in
everybody's `/` menu with somebody's name on it, and saving is also how an edit is spelled, so an
unattended save could replace a skill somebody is already using.

The tools run in the browser as the signed-in person, over the same `POST /api/plugins/skills` a
person uses, so who may take a slug is answered the same way and the `configuration.changed` audit
row is written the same way.

### Resetting a computer clears the activity pane

Resetting a Bot's computer deletes the browser profile it worked on, but the activity pane beside the
chat went on listing the commands and file operations that ran there. They sat alongside anything the
Bot did afterwards with nothing to tell the two apart, and only reloading the page cleared them. The
pane now forgets a Bot's history when that Bot's computer is reset. Stopping a browser is unchanged:
the profile survives a stop and is meant to resume, so what it did is still true of the machine.

### A person can set standing instructions that every coworker follows

Settings now has a box for standing instructions: one piece of text per person, saved once and
spliced into every built-in coworker's prompt, in every channel, on every run, including the runs a
routine starts overnight. It is the place for what is true of every task rather than of any one of
them, such as how somebody wants to be written to or what their company is and is not to be called.
A coworker's role still decides what it does; these decide how it does it, and the prompt says so,
so an instruction cannot quietly redefine what a coworker is for.

Instructions belong to the person who wrote them. Nobody, administrators included, can read or set
somebody else's, and they are deleted with the account. A coworker running at a remote AG-UI
endpoint is not sent them, since this deployment does not compose that prompt. Nothing is added to
any prompt until somebody writes something, so a deployment where nobody uses this behaves exactly
as before.

This adds migration `0026_user_instructions`, which creates one table.

### A coworker can be made in the conversation, and it starts able to reach nothing

A coworker without an endpoint runs on its role description, which becomes the standing instruction
handed to a model on every turn in every channel it is in. It is the hardest thing anybody is asked
to write cold, so people write a sentence, get a coworker that answers vaguely, and never go back to
the field that decided everything.

The example package now ships a `bot-creator` skill, granted to `general-assistant`, with tools for
listing, reading and saving coworkers. It asks the follow-up your last answer calls for, reads the
roster to say when something already does the job, and can be told to make one like an existing
coworker but for a different job, then go and read what that coworker actually runs on.

The card shows the name, the job, the skills and the entire role description, scrolled rather than
clamped, because that text runs on somebody's behalf. What is made is granted nothing: it can reach
no connector, no tool and no browser until somebody grants it, and a conversation with it says so.

Like the skill tools above, these run in the browser as the signed-in person over the endpoints a
person uses, so who may create a coworker is answered the same way and `bot.created` carries the
actor.

### A conversation has a name of its own

A channel's name was only the names of the Bots in it, so asking one Bot about six unrelated things
gave six rows reading the same thing, told apart by a preview of whatever was said last, which is
usually the tail of an answer and says nothing about the question. A conversation is now named from
its opening exchange, and the roster's second line holds that name instead of the preview, falling
back to the preview until a name exists. A row is never blank and never worse off than before.

Two things a deployment should know. The opening exchange, up to 600 code points, is sent to whatever
`tenantPackage.model` names, which is the same provider the Bots already use, so it is not new egress
but it is sent as housekeeping rather than because somebody asked for it. And the second line now
says what the conversation is about instead of what was last said.

It runs on the work queue rather than as a headless turn, so naming a conversation never takes the
Intelligence thread lock and cannot refuse somebody's own next message with a 409. A deployment with
no model key names nothing and carries on.

### The trail says who a coworker was opened to

Making a coworker public admits every signed-in person to it, and being admitted to a coworker is
being allowed to act as it — with the connectors, the tools and the browser it was granted. It is one
click in the coworker dialog. The `bot.created` and `bot.updated` rows recorded the name, the
endpoint and whether a key was set, and said nothing about this, so an edit that opened a coworker to
the whole deployment was byte-identical on the audit page to one that corrected its title. Both rows
now carry the visibility, on every edit rather than only the edit that moved it, so reading the trail
forward says who could reach each coworker at any point.

### Duplicating a Bot in the box keeps its instructions

A coworker that runs on this deployment's own Bot has no endpoint — it has a prompt, which is the
whole of what makes it that coworker. Duplicate rebuilt every copy from the endpoint alone, found
none, and fell back to the managed Bot with the prompt dropped, so the copy carried the name, the
title, the role and the avatar and none of the instructions. Its entire instruction became the one
sentence of role description, which is the shape behind the compliance answer this repository
already has a note about. The two coworkers the default package ships are both of this kind, and one
of them is a careful do-not-fabricate instruction. A copy now keeps the prompt and stays a Bot in the
box, which also means it can still be granted the right to hand work on — written as a hosted
coworker it could never hold that grant, however the original was set up — and copying one no longer
needs a managed Bot to fall back to.

### Hiding a coworker no longer hides the grants pointing at it

Hiding a coworker is a preference about your own roster — one row per person — and the grants saying
which Bots may hand work to it are a deployment-wide fact an administrator set. The Handoff section
joined the two, so hiding a coworker from your roster took every grant aimed at it off the screen:
the switch was gone, no note said why, and the count above the list quietly dropped by one. Those
grants were still in force, because a hop is decided by the grant and not by anybody's roster, so
the coworker went on being asked while the only screen that could stop it had stopped listing it.
A coworker you have hidden now appears in that list when a grant already points at it, marked as
hidden from your roster, so it can be switched off. One you have hidden with nothing granted to it
stays hidden.

### A tool call that failed no longer reads as one that worked

The audit page draws a row it does not recognise as `Allowed`, which is right for the many rows that
are neither a refusal nor a failure. Two rows that are failures were falling through to it: a
connector tool call this deployment permitted and the vendor did not complete, and a component's
data read that was granted and then broke. Both were drawn in the same muted colour as a call that
went through, and neither appeared under `Did not happen`, so the view an administrator opens to ask
what did not work here was short by exactly the rows they came for. A per-person connector fails on
this path every time somebody's token expires, so this was the most common failure the product has
and the one the trail was quietest about. Both now read as `Did not happen`, and both are in that
saved view. Neither is filed as a refusal: nothing was forbidden on either row.

### A blank agentId on a channel activity says which field was wrong

`POST /api/channels/:id/activity` accepted an `agentId` of only spaces, trimmed it to nothing, then
looked that up and answered `404 Agent not found`. The field was malformed rather than the agent
missing, so the answer sent whoever was integrating to look for a coworker that was never named. It
is now a `400` naming the field, which is what the same endpoint already did for malformed text.

### Audit payloads are redacted by the store as well as by its caller

Redaction of secrets out of audit payloads happened in `recordAuditEvent`, and every caller in the
tree goes through it. The store underneath it is exported, though, and its `insert` wrote whatever it
was handed, so a future direct caller would have written secrets to the audit table in cleartext.
`insert` now redacts too. Redaction is idempotent, so nothing about the existing path changes; this
is the floor under it rather than a fix to it.

### A stray space in NODE_ENV no longer lets the public example key through

A deployment that never changed `KEY_ENCRYPTION_KEY` encrypts its credential vault with the key
printed in `.env.example`, so the server refuses to start with it under `NODE_ENV=production`. That
refusal compared the variable exactly as written, while the other production refusal beside it —
private-host browsing — trimmed first. Both read the same env file, and a trailing space there is
invisible: Docker's `env_file` preserves it and so does every hosting dashboard with a text box. So
`NODE_ENV=production ` tripped one refusal, slipped past the other, and started the deployment on the
public key with only a warning at boot. Both gates now ask the same question the same way.

### A tool result from an MCP server with an empty part no longer crashes the turn

Reading a tool result cast every part to an object and asked for its type. A `null` or missing entry,
which a vendor's MCP server is free to send, threw instead, and the turn that had just called the
tool failed. Such a part is now named `[unknown]`, which is the same naming-rather-than-dropping the
surrounding code already does for parts it does not recognise, so the rest of the result still
reaches the Bot.

## 0.0.6

### Setting up needs one Intelligence credential, not two

`COPILOTKIT_LICENSE_TOKEN` is no longer required. Managed Intelligence derives entitlement from the
project key, so the second credential people were sent to fetch had stopped existing, and startup
was still refusing to boot without it. A deployment now needs `INTELLIGENCE_API_URL`,
`INTELLIGENCE_GATEWAY_WS_URL` and `INTELLIGENCE_API_KEY`. A licence token is still read and still
forwarded to the runtime when set, which is what a self-hosted Intelligence with its own licence
needs.

The Helm chart failed harder than the docs did: it *required* `secrets.licenseToken`, so a
managed-Intelligence install was refused at `helm install` rather than merely misdocumented. That
value is now optional.

### Duplicating a coworker keeps the endpoint it was copied from

Duplicate used to point every copy at this deployment's own managed Bot, whatever the coworker being
copied ran on. Duplicating one you host yourself gave back something that looked identical on every
screen, carried the same name, title and role, and answered from a different process. The copy's
connection tab then said it ran here and stopped showing an endpoint at all, so the swap was
invisible in the one place you would have checked. A copy now runs where its original ran, and the
managed Bot is used only when the coworker being copied had no endpoint of its own, which is the
same fallback that applies when you create one without an endpoint. It does not inherit the
original's key: that is a reference into the vault, and two coworkers sharing one credential would
mean rotating either one's key silently changed the other's, so a copy starts without one. On a
deployment with no managed Bot configured, duplicating a coworker that brought its own endpoint now
works instead of being refused with advice to give it an endpoint it already had.

### Connecting an account survives a vendor that is down

Finishing a connection used to end on a blank server error if the vendor could not be reached at the
moment you were sent back, whether that was a refused connection, a name that would not resolve, or
fifteen seconds of silence. It now ends where every other failed connect already ended: back on
Connected accounts with a note, and nothing stored. Pressing Connect for a vendor this deployment
has not introduced itself to yet behaves the same way, answering 502 rather than a server error, and
that message now covers a vendor that could not be reached as well as one that turned the
registration down.

A connection whose grant cannot be written to the vault ends the same way, rather than on the blank
error it used to give somebody who had just finished consenting.

Because the person is told the same thing whatever went wrong, the server log is now where the
difference lives. Three lines to look for: `oauth-token-endpoint-unreachable` and
`oauth-registration-endpoint-unreachable` name the vendor and the cause, and
`oauth-connection-not-recorded` says a consent completed and could not be kept. A fourth,
`oauth-token-endpoint-unusable`, means the fault is this deployment's catalogue rather than the
vendor.

### A custom MCP server token is sent with the scheme it names

Every token stored against a custom MCP server went out as `Bearer`, whatever the vendor asked for.
A server that forwards the header to an API speaking Basic auth still answers the handshake and the
tool listing, so the Plugins page showed the connector connected and its tools offered, and every
real call came back 401. DataForSEO's hosted server behaves exactly this way.

A token that begins with `Basic ` or `Bearer ` is now sent as written, so paste the credential the
vendor gives you, scheme and all. A bare token is still sent as `Bearer`, so nothing already
working needs to change.

### A conversation is no longer stuck after a tool call went unanswered

A tool that runs in the browser can be torn down while its call is still open, most often because
the tab was closed or reloaded mid-run. The call stayed in the thread with no result, every retry
sent it back up, and the model API refused the whole conversation with `Tool result is missing for
tool call ...`. The next three things the person typed failed identically, and the only way out was
to notice that and start another channel.

A chat turn now drops a tool call nothing is going to answer before the conversation reaches the
model, on a built-in Bot and on a remote one alike. Routines already did this for the history they
seed, and now share the one filter, with a stricter rule than theirs was: a result counts as an
answer only if it arrives before the next thing the person said, matching what the model API
enforces, so a handler that resolves after the person has typed again no longer looks like an
answer. A routine's seeded history that held such a late result used to keep both halves and fail
at the model; it now drops both and runs. A result that sits ahead of its own call, or a second
answer to a call already answered, is dropped as well rather than sent where no provider accepts
it. Ids are never rewritten and the stored thread is untouched, so the transcript still shows what
happened and a call waiting on a resume still gets its result. The same filter also covers a Bot
answering a relayed question, whose seeded conversation kept every tool call and no tool result.

### Reopening a channel no longer hides the end of the last conversation

Opening a channel joins the realtime gateway, and the snapshot the join returns can lag the durable
store. When it did, the last exchange of a finished turn was missing from the transcript on every
reload, with no unread marker or anything else to explain the gap, and the stored copy never got a
chance to replace it because history was only restored into an empty channel.

The stored thread now wins whenever it holds more than the channel does and holds everything the
channel already shows. A message typed while history is still loading is not in the store yet, and
a run still streaming has messages the store has not seen, so neither is rolled back.

### The transcript stays with the question when an answer starts arriving

Sending a message carried it up to the top of the view, correctly, and then the Bot's first token
threw the conversation back to its very first message, with the answer being written several
screens below the fold. It happened on every turn, from wherever the reader happened to be
scrolled, so every answer began with a scroll back down to find it. The transcript now holds the
question in place for the whole turn, and the scroll that puts it there is animated rather than a
jump — unless the reader has asked their system for reduced motion.

### A conversation started from the sidebar is recorded like one started from the home screen

The trail had a `channel.routed` row for every conversation begun in the home composer — the
coworker it went to and why, whether inferred or named with `@` — and nothing at all for one begun
from the sidebar's +, a coworker's card or its profile, which read exactly like a row that failed
to write. Picking a coworker in that To: field is now recorded the same way an `@` is.

### A browser clock that runs ahead no longer hides what a routine said

The roster line and unread dot for a channel are moved by the last report that arrived, and only
ever forwards. A browser whose clock was ahead stamped its report into the future, and then every
report from a correct clock — a routine's reply, a relayed handoff answer, another member's browser
— was dropped without a word until the real time caught up: the reply was in the thread, and the
roster never said so. A reported time is now capped at the server's own clock.

### An empty supervisor PORT is unset, not an ephemeral bind

`PORT=` left blank in compose or a `.env` used to reach `Bun.serve` as `NaN`, so the supervisor
bound a random port while the published mapping still pointed at 4300. Empty now means the default
4300; a non-numeric or out-of-range value refuses to start instead of binding port 30 from a typo
like `30o0`.

### Tool arguments and results are redacted in the audit trail whatever their spelling

The sensitive-key list redacted `tool_result` and `tool_arguments` but not `toolResult` and
`toolArguments`, which is the spelling MCP and computer tool calls use. Those payloads were stored
verbatim in `audit_events.payload`, nested ones included, while every other sensitive key already
carried both spellings. New rows are redacted; rows already written are not rewritten, so a
deployment that has been running MCP or computer tools still holds unredacted arguments and results
in its existing trail.

### An IPv6 address listed in `AGENT_ENDPOINT_ALLOWED_HOSTS` is now actually allowed

A bracketed IPv6 host was normalised one way when the list was read and another way when an endpoint
was checked, so the two could never match: `[::1]:8080` became `::1]:8080` on one side and
`::1:8080` on the other. Registering a Bot at a listed IPv6 address was refused as a private
address anyway. IPv4 was unaffected.

### An empty `PORT` no longer starts the server on a port nobody asked for

`PORT` and `SERVER_PORT` name one number, and either is meant to move the server. A `PORT` that was
declared but empty — a compose file passing a variable the host never set, or `PORT=` left in a
`.env` next to a `SERVER_PORT` that was set — was read as "set to nothing": `SERVER_PORT` was
ignored, the number parsed to `NaN`, and the server came up on an ephemeral port while everything
that polls `SERVER_PORT` reported it had never started. An empty value now counts as unset, the way
every other setting already treats it, and a value that is not a whole port number (`30o1` used to
start the server on port 30) refuses to start instead.

### `TRUSTED_ORIGINS` falls back to the port the app is actually served on

Unset, it fell back to `http://localhost:3000`, while the app is served on 3010 everywhere else in
this repository. `appUrl` reads the first trusted origin, so a deployment that left the variable
blank built OAuth redirects against a port nothing was listening on.

### Coworkers are made in a wizard and managed in a dialog

Creating a coworker is now a three-step wizard — who it is, who may see it, then where it runs,
with **Built in** offered only when the deployment actually has a managed Bot to run it on.
Managing one is a dialog opened from wherever the coworker appears, with sections for its profile
(each field edited in place), what it may reach, its connection, handoff grants, routines, and the
hide/duplicate/delete verbs — usable on a phone, where the old side panel hid most of this. The
panel beside a conversation slims down to who-you-are-talking-to plus two buttons: start a new
channel, or open that dialog.

### Routines live on each coworker

The sidebar's global Routines entry is gone; a coworker's routines are a section of its own dialog,
since a routine is something *it* carries out. The `/routines` page still answers direct links.
Each routine row now wears its state as chips — the channel it posts to, how the last run went, and
either the next run, **Paused**, or **Due** when a firing is waiting on the sweep (which used to
render as "Next 5 hours ago").

### A built-in coworker is no longer asked for credentials it will never need

A coworker running on the deployment's own Bot was nagged for a callback token and shown an
endpoint form. Its connection tab now says what is true — it runs here, nothing to connect, nothing
to authenticate. In the same spirit, the handoff panel explains once when a coworker cannot hand
work on (it runs as its own agent, outside this deployment's loop) instead of offering switches the
server can only refuse; its existing grants stay visible so they can still be revoked.

### A conversation is given a name of its own

A channel was labelled with the names of the Bots in it, so every conversation with the same
coworker read the same on the roster, and the only thing telling two of them apart was a preview of
whatever was said last. That preview is usually the tail of an answer, which says nothing about the
question that prompted it. Once a conversation has an opening exchange, the deployment's own model
is asked for a few words naming what it is about, and the roster draws those words in place of the
preview. A deployment with no model key configured names nothing and looks exactly as it did before.

### A channel stops showing a working indicator once its turn has ended

Sending a message and then opening another channel before the reply arrived left the first channel
showing three bouncing dots on the roster, and they stayed there after the answer had landed and
been drawn into its preview, until the roster was refetched for some unrelated reason. A person's
own turn is reported by the browser, because the server is not told when one begins, and that
reporting was keyed on state belonging to the channel screen: opening another channel replaced the
screen, and the replacement reported the channel it had just opened rather than the one still
working. The report now belongs to the turn instead of to the screen, so the channel that was
running is the channel told when it stops. Opening a channel also no longer announces that it is
idle twice before anything has run in it.

### A hop the boundary refused now names the Bot that was refused

The audit page renders its Bot column from `payload.bot` and nothing else. `agent.handoff_offered`
and `agent.handoff_delivered` were given that key; the four rows either side of them — a hop
refused, a hop retried, and a hop that failed for good — were not, so they showed a dash where the
Bot belongs. Those are the rows somebody actually opens the trail for: a hop that happened is visible
in the transcript anyway, and a refused or lost one is visible nowhere else. All four now name the
asking Bot, exactly as the accepted pair and `agent.escalated` already did.

### A failed tool refresh no longer leaves a connector offering nothing

Refreshing a connector's tools replaced the list with a delete and then an insert, as two separate
statements. Whenever the second did not land — a pod killed mid-refresh, a dropped connection, or a
server answering `tools/list` with the same tool name twice, which the table refuses — the delete had
already committed on its own. The table is shared, so every replica lost that connector's tools at
once, every grant an administrator had made was silently un-offered, and the Bot was told it holds
none of that vendor's tools. Nothing brought them back until somebody read the error on the Plugins
page and pressed Refresh. The two statements are now one, so a bad refresh is recorded and the tools
already held are left alone, which is what the code always claimed to do.

### A rule tried in dry-run now says what it would have refused a Bot's tools

`dry-run` exists so a boundary can be measured against live traffic before it starts refusing
anybody. It worked that way for the browser, and not for connectors: a tool call the rule matched was
recorded only as the call that then went out, so `Blocked` on the audit page — and any query behind
it — answered "this rule would have refused none of them" about calls it would have refused. A rule
about `mcp.server`, `mcp.tool` or `mcp.effect` therefore looked inert, and enforcing it started
refusing Bots with nothing in the trail to have warned anybody. A refused tool call is now recorded
whatever the mode does with it, carrying `carriedOut` so a reader can tell a call this deployment
stopped from one dry-run recorded and let past. Enforcing deployments behave exactly as before.

### A policy dry-run no longer counts a failed action twice, or invents a change it did not make

Testing a boundary against recent history replayed three kinds of audit row, and one of them is a
duplicate: a permitted action that fails is recorded both as the decision that allowed it and as a
separate failure row, so every failed action was scanned and scored twice. Worse, a dry-run policy
carries a refused action out, so a refused action can fail too — and its two rows disagree, the
decision row saying "refused" and the failure row reading as "allowed", so a candidate policy that
refused it identically was reported as a new refusal it never introduced. The replay now scores each
action once, from the row that recorded its decision.

### A message no longer routes to a specialist because a longer word contained a connector's name

When the intent router falls back — it is unreachable, or it declines — and exactly one coworker can
reach a system the message names, the message goes to that coworker. The name was matched as a bare
substring, so "how do I deal with a slacker" matched the **slack** connector and "una jirafa" (a
giraffe) matched **jira**: a message naming neither system was pinned, for the life of the thread,
to a specialist that could not answer it. A connector's name now has to appear on a word boundary,
so a system named on its own still routes and one buried inside another word does not.

### The audit page no longer says "Allowed" about six kinds of refusal

A hop one Bot was not allowed to make, an endpoint this deployment would not dial, a rotation the
vault refused and a sign-in it turned away were all drawn as **Allowed**, in the muted colour every
ordinary row uses, and none of them appeared under **Blocked**. The same for a hop that ran out of
attempts and a question that reached nobody, which are "Did not happen" rather than allowed. The
page recognised six refusal types and the six added since were never added to it. Refusals now read
as refusals, the two saved views are built from the same lists the rows are labelled from, and a
refusal added later is added in one place or in none.

### A conversation deleted while a server was reconnecting no longer lingers on the screen

Announcements between servers travel as Postgres notifications, which reach whoever is subscribed at
the moment they are sent and are never replayed. While a server's subscription was down — a database
restart, a failover, a rolling upgrade — every channel deletion, pin and message announced in that
window was lost, and nothing afterwards asked for it again.

The browser could not notice. Its own connection to the server stayed open throughout, so the
refetch it already does when that connection comes back was never triggered, and the roster went on
showing a conversation that had been deleted until the page was reloaded.

A server now tells the browsers it is holding to refetch when its subscription is re-established.
Nothing to configure, and no change for a deployment whose database connection never drops.

### A Bot can answer with a picture instead of describing one

Ask for a chart and a Bot replied in prose, or handed back a fenced block of HTML for somebody to
read instead of look at. Set `OPENBOT_GENERATIVE_UI=true` and it may answer with an interface it
writes itself, drawn in the transcript. Off unless asked for, and deliberately so: it runs code a
model wrote, so a deployment acquires the capability by choosing it rather than by upgrading.

### The sidebar collapses, and the roster is reachable on a phone

The sidebar could always collapse, but nothing in the app ever drew the trigger. The only
affordance was a 16px transparent rail carrying `tabIndex={-1}`, which the eye could not find and
the keyboard could not reach. Below 768px that same sidebar becomes a sheet whose open state starts
false, so with no trigger the roster was unreachable on a phone, and the roster is how you reach a
channel, Skills, Agents and your own account. There is now a toggle in the header each screen
already draws, with Cmd/Ctrl+B on it, and the collapsed choice survives a reload: the state was
written to a cookie that nothing ever read back. Fifteen screens that previously drew no header bar
gain 40px above their heading, because the toggle has to sit at the pane's edge.

### A button drawn as a link answers the keyboard and announces itself

Six controls navigate rather than submit, so they render a router link through the shared button:
New skill, New agent, the sidebar's new-channel control, two empty-state returns, and the back
button that draws on five routes. Base UI was told each was a native `<button>`, so it wrote
`type="button"` onto an anchor, where it means nothing, and skipped the two things a non-button
needs: the `role="button"` that tells a screen reader what the control is, and Space-key
activation, which a `<button>` gets from the browser and an anchor does not.

### A Bot's answer comes back to the conversation that asked

**This reverses what 0.0.5 shipped.** The 0.0.5 notes below say the asking Bot does not relay text
on the addressed Bot's behalf, and the answer lands in that Bot's own conversation. In practice
that meant reading the answer somewhere you never asked anything, so it is now the other way
around: the addressed Bot works in a scratch conversation nobody is shown, and the asking Bot
relays what came back — attributed by name — into the conversation you are watching. What you read
is the asking Bot's account of the answer rather than the answer verbatim; very long answers are
clipped to keep the relay itself from failing.

### Channels say when a Bot is working in them

A channel whose Bot is mid-turn shows a working indicator on its roster avatar — including turns no
browser started, such as a handoff running on the server or a routine. An open conversation also
picks up turns that arrived while nobody here streamed them, so a relayed answer appears without
leaving and coming back.

### First sign-in gets an onboarding wizard

A new person lands in a short welcome wizard before the app; everyone who signed in before this
upgrade is stamped as already onboarded by the migration and sees nothing.

### Shift+N starts a new chat from anywhere

Bound across the signed-in app, shown under **Settings → Keyboard shortcuts**, and inert while you
are typing in a field. Handoff work is also picked up the moment it is queued rather than at the
next poll, so an answer's round trip no longer pays up to two seconds per leg.

### A Bot's shell can no longer reach the embedded database without a password

In the all-in-one image the cluster was `trust`-auth on loopback, and the Bot's shell runs in the
same container: it could `psql -h 127.0.0.1 -U openbot` with no password and read the audit trail,
the policy store, and the credential vault as the instance owner. The cluster now uses
`scram-sha-256` with a password generated on first init and kept beside the data, handed to the API
over the container environment. The shell has no way to learn it, so the connection is refused. An
external `DATABASE_URL` deployment is unaffected.

### A live screen that ends says so, instead of freezing the last frame

When a Bot's live screen ended — the computer stopped, or the socket failed — the message explaining
why was drawn only by a component the take-the-wheel view does not mount, so the screen sat frozen on
its last frame with nothing said. The reason is now shown where the live screen is.

### A Bot's browser drops the automation flags a person needs gone to sign in

The browser announced itself as automated (`navigator.webdriver`, the enable-automation switch),
which sites like Google refuse even when a real person has taken the wheel. Those flags are now off
at the source — the browser flag, not a script that patches `navigator.webdriver` and leaves the
other tells. A headless build still reports `HeadlessChrome` in its user agent, which only running
headed under a virtual display removes; that heavier change is tracked separately.

### An empty model reply, or a run with no question, no longer ends in silence

Two failures on strict OpenAI-compatible providers (z.ai GLM, Anthropic): a follow-up run that
carried only tool deltas and no human turn was refused outright, and a reply with no text and no tool
call ended the run with nothing on screen. A run with no human turn now carries a neutral
continuation, and an empty reply ends on a visible line rather than in silence. OpenAI, which
tolerated both, is unchanged.

### Embedded PostgreSQL initialises on a platform volume, and says so when it cannot

`EMBEDDED_POSTGRES=on` could not create its cluster on a platform whose persistent volume is an ext4
mount — Railway, and by the same mechanism most others — and it failed differently depending on where
the volume was mounted. Neither of the two paths this repo suggested worked, and the two suggestions
disagreed with each other: `docs/deployment.md` said `/var/lib/postgresql/data`, the `Dockerfile`
comment said `/var/lib/postgresql`.

Mounted at the parent, the mount arrives owned by root, `data` is not in it, and the image's
build-time `chown` is hidden underneath — so `initdb`, which has already dropped to the `postgres`
user, cannot create the directory. `postgres-init` now creates and chowns it first, as root, which is
the only step in a position to. This also fixes the plain
`docker run -v openbot-data:/var/lib/postgresql` case, which relied entirely on that hidden chown.

Mounted directly on the data directory, the mount arrives holding a `lost+found`, and `initdb` will
not initialise into a directory with anything in it. **The documented mount is now the parent,
`/var/lib/postgresql`**, which leaves `data` an ordinary subdirectory — what PostgreSQL's own hint
asks for, and what the `Dockerfile` already said. A volume already mounted at
`/var/lib/postgresql/data` and working — a Docker named volume, which arrives empty rather than with a
`lost+found` — keeps working and needs no change.

**The failure said nothing useful.** `api` waits on `postgres` and `migrate`, so neither started, the
container came up anyway, the platform reported the deploy a success, and the public URL served a
persistent 502 with the real reason visible only in the container log. A data directory that holds no
cluster and is not empty is now refused with a sentence naming the mount to use instead.

Reported by [@jerelvelarde](https://github.com/CopilotKit/OpenBot/issues/269) with the container logs
for both mount paths, which is what made the two failure modes separable.

### Turning on network policies no longer leaves the culler pod open

`networkPolicy.enabled` rendered policies selecting the server and the computers. The culler
CronJob's pod carries `component: culler` and was selected by neither, and a pod no policy selects
keeps the cluster default rather than being denied. So the switch fenced the API and the computers
and left open the one pod that wakes every five minutes carrying the API's whole environment,
`KEY_ENCRYPTION_KEY` and `BETTER_AUTH_SECRET` included, with a token allowed to create, patch and
delete Sandboxes. It has a third policy now, narrower than the other two, and
`networkPolicy.cullerExtraEgress` narrows its database egress separately from `extraEgress`. A
render that leaves any pod unfenced is refused by the chart checks.

### A sign-in a site opens in a new window is shown, and can be clicked

A Bot's browser was bound to the page it launched with, and to nothing the site opened afterwards.
Anything arriving in a new window or tab was invisible on the live screen and unreachable by input,
so the popup sign-ins that a person takes the wheel to complete were exactly the ones they could not
complete. Worse than invisible: a click at the place the popup's button was drawn went to the page
underneath it, so a person trying to finish a sign-in could navigate the page the Bot was working on
without seeing either result.

The browser now follows the window the site opens, and returns to the opener when it closes, which is
what a sign-in popup does when it succeeds. A snapshot taken before the change of page is refused
afterwards with the same "take a new snapshot" it already gives after a navigation, so a stale ref
cannot act on the wrong document.

Nothing to configure.

### Stopping a Bot's computer stops it, and the person watching is told

A computer somebody stopped came back up on its own about a second later, and reset did the same. The
live screen kept a loop asking for the Bot's current page once a second, asking for a page is what
starts a browser, and nothing tore that loop down when the browser it was showing went away. The same
loop kept the browser marked recently used, so a Bot with somebody watching was also immune to the
idle timeout and came straight back after being closed to stay under the cap on running browsers.
Those last two never involved a request at all, so nothing on the stop path could have covered them.

Two smaller failures went with it. A person who reconnected, leaving their old window open, could
have that old window's typing land in the page the new one was watching, with nothing said to either.
And a window closed while the browser was still starting left a screencast and its loop behind for a
connection that had already gone.

The screen is now held per connection rather than per Bot, so closing one only ever ends its own, and
teardown hangs off the browser closing rather than off the two requests that ask for it. A viewer
whose screen ends is sent a message saying why, whether the computer stopped, was reset, or the
screen was taken over by another window.

Nothing to configure, and no change for a deployment where nobody watches a Bot work. **The app does
not yet show that message**: it arrives at the browser and is held in state the live screen does not
read, so a person still sees the last frame until they reopen the screen. That half is tracked
separately in #287.

## 0.0.5

### One Bot can hand work to another, and reach a person when no Bot will do

A Bot asked something it is not the right Bot for can now put the question to one that is. The
addressed Bot answers **as itself, in its own conversation**, with its own tools and its own
knowledge. The asking Bot does not relay text on its behalf, so what you read is the answer that
Bot actually gave rather than another Bot's summary of it. *(Reversed since: see Unreleased — the
answer is now relayed back into the conversation that asked.)* The asking conversation records
that the question was put and to whom. A Bot that judges no other Bot will do can instead reach
the person who asked it.

**No Bot may address any other until an administrator says so.** Which Bot may reach which is an
ordinary grant, made per Bot on that Bot's own screen under **Bots it may ask**, and a Bot with no
grant is told it cannot rather than quietly trying. The pair is directional: that list is who this
Bot may ask, not who may ask it, so letting two Bots ask each other is two switches. A Bot addressed
by a name two Bots answer to is refused and both are named, because picking one would be a guess
about which colleague a person meant.

Two ceilings, because a Bot deciding to ask another Bot is a Bot deciding to spend a run:
`BOT_HANDOFF_MAX_DEPTH` is how many Bots deep a chain may go and defaults to `1`, and **`0` switches
the capability off entirely**: the tool is not offered rather than offered and refused.
`BOT_HANDOFF_MAX_PER_RUN` is how many Bots one run may address and defaults to `3`. The Helm chart
takes the same two as `config.handoff.maxDepth` and `config.handoff.maxPerRun`.

A hop that fails is reported back by the Bot that asked, after its attempts are spent, rather than
leaving the person watching a conversation that never finishes. One rough edge to know about: a hop
that is retried leaves one "asked" line per attempt in the addressed Bot's own transcript, so a hop
that took three attempts reads there as having been asked three times.

No new tables: this uses the work queue that already fires the culler.

### A conversation that used a tool no longer stops answering for good

A channel could reach a state where every turn in it failed and the only thing it said was
`Tool result is missing for tool call call_…`. Not the turn: the conversation. Everything sent
afterwards failed the same way, including a question as ordinary as what two plus two is, and there
was nothing a person could do to it from the screen.

A tool result is matched to the call above it, and a thread read back from the platform does not
always carry the two in that order. Where the result was stored ahead of its own call, this
deployment counted the call answered, sent the history on unchanged, and the model provider rejected
the whole conversation while assembling it. Handing work to another Bot, asking a person, and
calling a connector's tool could each leave a thread in that shape.

A result now only answers a call it follows. One that arrives early is moved to sit after its call,
keeping what it actually said, and a result whose call is nowhere in the thread is dropped. Affected
conversations start answering again on their own; there is nothing to run and nothing to reset.

### The framework Bot answers on 5.6-tier models, and can be told how hard to think

Pointing `BOT_MODEL` at a `gpt-5.6-*` model gave a Bot that started, reported healthy, and then said
nothing: every run was a RUN_STARTED and a RUN_FINISHED with no text between them. Those models are
run on the Responses API, which streams content blocks where chat completions streams a string, and
the run read only the string — so every delta was dropped on the floor. Both shapes are read now.
Nothing changes for a deployment on 5.5 or on Anthropic or Google.

`BOT_REASONING_EFFORT` sets how hard a reasoning model thinks: `none`, `minimal`, `low`, `medium`,
`high`, `xhigh` or `max`. Unset, the model keeps its provider's default. A value the API does not
have, or one set where it cannot be sent — a provider that is not OpenAI, or a model not on the
Responses API — stops the Bot at startup with a message naming what to change, rather than starting
with a setting that goes nowhere.

### A Bot can be asked to do something on a schedule

"Every weekday at nine, post the standup notes here" is now something a Bot can be asked rather than
something somebody has to remember. A routine created this way runs under its own creator's grants —
it can do exactly what they could do in chat, and nothing more — and its reply lands in the channel as
an ordinary Bot message: it lights the unread dot the same way any other message does, and it appears
in the transcript rather than anywhere separate. A routine that fails posts one message about its
first failure and, after ten in a row, switches itself off with a final one rather than failing
forever unnoticed.

The deployment gains two tables, via migration `0021`.

**This needs a new process.** A worker fires due routines by calling this deployment's own API server,
and a deployment that never starts one schedules nothing — the routine sits on the Routines page with
a next run time like any other, and nothing on the screen says a worker is missing. `WORKER_SHARED_SECRET`
is the credential the worker presents; a deployment without it configured refuses every handoff rather
than accepting one it cannot attribute. `scripts/start.sh` runs the worker locally; the Helm chart
turns it on with `routines.enabled` and takes the secret as `secrets.workerSharedSecret`. No new port
is opened for any of this — the worker only ever calls out to the server it already trusts.

### Turn screenshots are swept in every deployment, not one

A page a Bot opens is photographed and kept in `computer_page_frame`, so a conversation read back
later shows what it was looking at. The reaper for those rows had one caller: the idle-computer
culler, which refuses to run unless each Bot has its own computer and is scheduled only by the Helm
chart's CronJob, which exists only when `computers.mode` is `sandbox`. On Compose, on the all-in-one
image, and on the chart's own default of `shared`, nothing ever called it. One browsing Bot over
ninety days is several hundred megabytes of rows that nothing was ever going to remove.

The sweep now runs on the server, on the same hourly timer that removes old audit rows, and does not
wait for a retention policy to be configured: a month of screenshots is what the store already meant
to keep. It also removes them in batches, because one statement over that much data held its locks
for seventeen seconds.

Deployments using `computers.mode: sandbox` are unaffected in what they keep. The culler no longer
purges frames, because the server does it there too and one owner is better than two.

**On upgrade, the first sweep removes the backlog.** A deployment that has been keeping every
screenshot since it was installed will lose the ones older than a month, about a minute after the
server starts. That is the window the store has always documented and the one sandbox deployments
have been enforcing, but it has never been applied anywhere else, so it is worth knowing before the
upgrade rather than after. It is drained in batches, forty thousand rows an hour, rather than in one
statement.

### A channel a Bot has spoken in unseen shows a dot

The sidebar marks a channel when a Bot has said something since you last had it open: a dot beside
the preview, the name a touch heavier. Opening the channel clears it, your own messages never set
it, and the channel you are looking at never shows it. The marker is yours alone — per member, on
the membership row like the pin — so one person reading does not clear anybody else's dot.

The deployment gains one nullable column, via migration `0019`.

### The API can reach Intelligence and sign-in when a NetworkPolicy is on

`networkPolicy.enabled` wrote a rule for the API server that named DNS, the database and the Bots'
computers, and nothing on 443. On a cluster that enforces policy the server could therefore reach
neither CopilotKit Intelligence, nor an identity provider, nor a Bot: nobody could sign in and no
conversation ran. Two of the five shipped `ci/` targets turn the policy on, and on GKE enforcement is
the default and cannot be switched off.

Nothing said so. The pod passed every probe and stayed Ready, because `/health` answers from a
literal, so the first evidence was a timeout to a hostname that read as the internet being down.

The API now reaches HTTP and HTTPS everywhere outside the cluster's private ranges, in every
`computers.mode` rather than only `sandbox`, cut by the same exception list the computers' own policy
uses. It still cannot address another pod, a node, or a cloud metadata endpoint.

`mode: sandbox` had been working only because a rule meant for the Kubernetes API server carried no
destination and so permitted everything. That rule now covers the API server alone, and
`networkPolicy.kubernetesApiCidr` narrows it to your cluster's service range; left empty it stays as
it was, because a chart cannot know that range.

### Taking the wheel stops the Bot's shell, not just its clicks

While a person held the wheel the Bot was refused on the page, and not in the shell. `/exec` and a
workspace write went through, so a Bot could keep running commands and rewriting its `/workspace`
underneath somebody who had taken the browser at a login wall. The guard existed and covered
navigation and the four page actions; the shell arrived later and was never wired to it.

Every acting path now asks the same question in one place, so the property the documentation states
is the property the computer has. Reading is deliberately not acting: `/files/read` and
`/files/list` still answer while a person drives, because a Bot that has just been stopped still has
to be able to say what it was doing.

Nothing to configure. A Bot that acts during a takeover gets the refusal it already got for a click,
and the trail records the attempt and the failure the same way.

### A computer that was suspended once suspends again

Scale-to-zero worked once per Bot. A computer suspended, resumed, used and then left alone again was
offered for suspension on every sweep after that and never suspended, and stayed awake until the next
day. Nothing reported it, because a sweep that offers work and suspends nothing looks exactly like a
fleet that is busy.

The queue keys a suspension on the Bot id and keeps the finished row so that a late offer of the same
key collides with it rather than running the work twice. Both are right. What was wrong is that the
finished row was kept for a day, which is the window the other half of the sweep needs: a suspension
that keeps failing is held back that long before anything tries it again. One number could not be
both, so there are now two, and a finished suspension is kept for the idle window instead. That is
the same clock the offer runs on, so a Bot cannot come back round as idle until its row has gone.

Nothing to configure, and the sweep already runs on a schedule. A deployment where each Bot has its
own computer stops paying for browsers that were used once.

### A Bot's egress proxy is reachable on Kubernetes, or the install is refused

The chart named no egress variable anywhere, so a Helm deployment read the per-Bot proxy settings
nowhere and every Bot went out directly. They were always settable through `computers.extraEnv`,
which reaches the computer in both the shared and the sandbox arrangement, but nothing in the chart
or its README said so, and a setting whose whole purpose is to give a security team a per-Bot
address is not one to leave undocumented.

The other half is that setting it was not enough. A computer is allowed 80 and 443 to public
addresses and nothing else, which is almost no proxies: they sit on a private address, or on 3128 or
8080. So a proxy the network policy provably blocks is now refused at `helm install`, naming
`networkPolicy.computerExtraEgress`, rather than found later as a Bot that fails on every page.
Nothing changes for a deployment that sets no proxy, or one that already opened a path to it.

### A finished turn shows the page it opened, not the one open now

Reopening a conversation made every past turn fetch the screen as it is now, so an answer about
Hacker News from an hour ago sat under a picture of whatever the Bot had open since.

A page is now photographed where it is opened. The server takes the frame the moment a navigation
succeeds and keeps it in `computer_page_frame` under the computer and the address, which is the one
moment the screen is certainly showing the page that was asked for. Reopening the conversation shows
that frame rather than the live screen, and a turn with nothing kept names the page instead of
drawing the wrong one.

The surface used to capture it itself once the turn went quiet, and that is a race it cannot win: a
reopened turn and one that has just finished are indistinguishable from inside the component, the
same computer is driven by other conversations in between, and a resumed computer starts blank. It
filed pictures of pages the turn never opened, or none at all. It only reads now.

**Redeploy the computers with the server.** A screenshot only says which page it is of on an
`agent-computer` built after that field was added, and this is what decides whether a frame is kept.
Where each Bot has a computer of its own there is nobody to race with, so an old computer's picture is
accepted and the feature works through a rollout. On ONE SHARED COMPUTER it cannot be: another Bot's
navigation lands between the navigation and the picture, and a frame that cannot be told apart from
theirs is refused. So a shared-computer deployment that updates the server and not the computer keeps
no frames until it does, and says so in the server log each time rather than leaving somebody to
wonder.

Two things followed from making a past turn a record. Its placeholder is decided by the turn being
over rather than by whether a live frame happens to be in hand, because a tile that was live a moment
ago keeps its last screenshot and used to fall through to "Waiting for the assistant's screen…" and
wait there for ever. And opening one full size shows that same kept frame, with no live stream and no
wheel: zooming a past turn used to mount the socket and offer Take control, so the one gesture for
looking closer at what a turn did replaced it with whatever the Bot has open now.

### A conversation keeps the browsing that produced its answers

Every turn in which a Bot used a tool was disappearing from the transcript on reload. The sentence
the Bot wrote stayed; the browsing that produced it did not, the inline screen went with it, and the
footer said some messages could not be read.

The history store writes a tool call as `{id, name, args}`. AG-UI describes
`{id, type: "function", function: {name, arguments}}`. The reader validated against the second,
treated the first as damage from an interrupted run, and dropped it. It is not damage: it is how
every tool call is stored, so what looked like a guard against one bad turn was deleting all of the
real ones. Observed on a live thread where every browsing turn was counted unreadable and every one
of them was well formed in the store's own dialect.

The two spellings are now read as the same thing. The check stays for turns that really are
malformed, and a mixed or unrecognised array is still refused rather than half-translated, because a
reader that rewrites what it does not recognise is worse than one that refuses it.

### Run this on Kubernetes

A Helm chart under `charts/openbot`, Bots and all, and the fixes that installing it for real turned
up. Proven on a real EKS cluster: five workloads, replicas across two nodes, EBS volumes bound, and a
Bot opening a real page from inside AWS with the decision in the audit trail.

One chart, five targets: EKS with a shared browser, EKS with a computer for each Bot, GKE, AKS and
somebody's own cluster, with nothing but values between them. There is no cloud branching in any template. Every place the clouds genuinely differ is a
value whose default is what a plain self-hosted cluster does: the cluster's own default StorageClass,
no RuntimeClass, a plain Kubernetes Secret, an Ingress. Identity is one `serviceAccount.annotations`
map, which is all IRSA, Workload Identity and AKS workload identity are. Secrets are a plain Secret
by default and an ExternalSecret against any backend when asked, so Secrets Manager, Secret Manager
and Key Vault are a values block rather than three code paths. Gateway API is supported beside
Ingress rather than instead of it. `charts/openbot/ci` holds a values file per target.

Two replicas by default, because horizontal is the point and one replica hides every bug that is
not. A bad install is refused at `helm install`, naming the value to change, rather than discovered
in a crash loop: no database or two of them, nobody who could sign in, nobody who would be an
administrator, a key of the wrong shape, both routers enabled, or a browser asked for inside more
than one replica.

**A Bot's computer is not in an API pod.** The image runs one beside the API so that a single
container works on its own, and `EMBEDDED_COMPUTER=off` turns it off. A replica must not carry a
browser: it is a few hundred megabytes holding one Bot's logins, so scaling the API would scale
those with it.

**Migrations no longer need a development tool.** `bun x drizzle-kit migrate` cannot run in the
shipped image at all. The CLI reads a TypeScript config, which needs the esbuild that
`bun install --production` correctly leaves out, so it printed "Reading config file", exited 1 and
said nothing else. `EMBEDDED_POSTGRES=on` was therefore starting a container whose database was
never migrated, and the first symptom was the API reporting that `users` does not exist.
`server/scripts/migrate.ts` uses the migrator inside `drizzle-orm`, which is a runtime dependency
already, and keeps the same journal, so a database migrated by either tool is migrated.

**A computer for each Bot, suspended when idle.** `computers.mode: sandbox` gives every Bot its own
browser as a `Sandbox` from `kubernetes-sigs/agent-sandbox`, which is built for this workload: an
isolated, stateful, singleton pod with a stable identity and persistent storage. Suspending is one
field, and it keeps the volumes, so a computer comes back with its logins rather than signed out of
everything. `shared` stays the default and needs nothing installed in the cluster.

**The NetworkPolicy would have fenced the API off from its own work.** Its egress named DNS and the
bundled database and nothing else, so on a cluster that enforces policy the API could not have
reached a Bot's computer or, with a managed database, the database. Both are allowed now, and turning
the policy on with an external database and no rule for it is refused rather than shipped. Worth
knowing either way: EKS runs its CNI with `--enable-network-policy=false`, so a policy there installs,
looks right, and does nothing at all.

**A cluster with no controller is refused at install.** `computers.mode: sandbox` needs the
agent-sandbox CRD, and without it the install succeeds, every pod is healthy, and the deployment
looks finished until the first Bot asks for a browser. The chart reads the cluster and refuses,
naming the one command that fixes it.

**What decides a computer is idle is the audit trail, not the browser.** Asking the browser would
wake it, so every computer anything asked about would come back up and the bill would never fall.

**Durable work, claimed by whichever replica gets there first.** `work_items` plus
`select ... for update skip locked` and a lease: no coordinator, no leader election, and a replica
added is throughput added. The idle-computer culler is its first user; scheduled routines and
hand-offs between Bots are the other two, which is why it is written once rather than three times
slightly differently. A CronJob runs the sweep, because a timer in the API fires in every replica and
suspending a browser somebody just started using is not something to do five times.

**Which run of a computer this is, across a suspend.** A resumed browser counts snapshot
generations from one again, so a ref the model still holds from before the suspend would match a row
nothing has overwritten and the boundary would decide about an element on a page that no longer
exists. The first answer here used the node and the pod address, and resuming a real computer
disproved it: a suspended sandbox is very often rescheduled onto the same node and handed the same
address back, so both were identical across a suspend and resume and the check would have said "same
run" for the exact case it exists to catch. It reads the `Ready` condition's transition time instead,
which moves every time a computer starts serving again.

**Which run of a computer this is, on more than one replica.** `sessionOf` answered from a map in
the process that started the computer, which is right until there are two: the replica that took a
snapshot is usually not the one handling the click, and the second had nothing to answer with. An
unknown session means "no opinion" and skips the generation check, so on exactly the deployment
shape it was written for, the check that stops a ref from a replaced computer resolving against a
live one was silently absent. It now asks the supervisor when it does not know, by listing rather
than by ensuring, so asking never starts a computer that had stopped.

### A routing trail says why a message was not routed, not only that it was not

Every untagged message writes a `channel.routed` row, and that row carried `fallback: true` for two
completely different situations: the router answering honestly that no specialist was a confident
match, which is the feature working, and the router not answering at all, which is an endpoint that is
down. Both read identically, so a deployment whose router had stopped working looked like one whose
messages were simply hard to route.

That is not hypothetical. The intent router spent an unknown period 404'ing on every deployment that
set `OPENAI_BASE_URL`, because a `/v1` was appended to a URL that already had one. It was fixed in
0.0.3, whose own note says untagged messages "silently stopped being routed and nothing said why".

The row now carries `undecided`, naming the cause: `unreachable`, `unparsed`, `off-roster`,
`unconfident`, or `one-candidate` — and `null` when the router did decide. Named values rather than a
sentence, because the useful question is how often, and a count needs something to group by.

Two smaller corrections came with it. A message routed to the only coworker that can reach the system
it names kept that as its reason and threw the cause away, so a router that had been down for a week
produced rows reading like reach-based routing working as intended; the cause now survives that path.
And an answer containing no JSON at all — a model replying in prose — was recorded as the router
naming a coworker off the roster, which sends whoever reads it to look at their roster rather than at
the model. It is now reported as unparsed, which is what it is.

Nothing changes about where a message goes. Every routing decision is the same decision it was.

### Notion joins the connector catalogue

Notion is now a governed MCP connector, reached through Notion's own hosted server on the
catalogue's default transport, as the person asking — the same grant, policy and audit machinery
Google Drive already runs through. Unlike Drive, it ships both read and write tools from the start;
the writing ones are named in the catalogue, and an advertised tool absent from that list classifies
as a read — so reconciling the write-tool names against what Notion's hosted server actually calls
them, on the first Refresh tools, is required, not cosmetic. A tool the server never advertised at
all still classifies as a write, same as any other connector.

There is no client to register: this deployment introduces itself to Notion on first connect. That
shortens setup but does not finish it — unlike Drive, whose tool list is this codebase's own code,
Notion's tool list is an answer from Notion's hosted server, so a deployment has recorded none of it
until Refresh tools has run at least once; and, like every other connector, a Bot gets nothing until
its tools are granted to it. Setup is enable at `/admin/plugins/notion`, connect an account at
`/settings/connected-accounts`, refresh tools, then grant — a bulk **Grant tools…** dialog on
`/admin/plugins/notion` grants a batch of tools to a batch of Bots in one pass, one grant and one
audit row per Bot per tool. No migration.

### Refresh tokens rotate in place, and replicas take turns spending them

A vendor that rotates refresh tokens invalidates the one it just handed out, so two replicas racing
to use a stale token would have the loser refused, or worse: a rotating vendor's reuse detection can
read that as a stolen token and revoke the whole connection. Every plugin call that mints an access
token now locks the credential's vault row for the length of the exchange, so a second replica waits
rather than races, and the rotated token is written back in the same transaction that held the lock.
Nothing to configure; a connection just stops going stale under concurrent traffic.

### An MCP token is spent only by its own server, and only at the address it was given

Pointing a server at a credential is the one place this deployment takes a reference to a stored
secret rather than the secret itself. Everywhere else, the value was typed into the same request that
stores it: a Bot's key is minted from what an administrator pasted and the id it gets is nobody's to
choose. So this is the one field where which secret and which address could be made to disagree, and
the add settles the disagreement by spending the credential: the tool refresh runs before the call
returns and sends what it decrypts to the URL from that same request.

Two ways they could disagree, and both are now refused. A server could be pointed at any `mcp`
credential in the vault, including one minted for a different vendor, so a token given to one server
was deliverable to another. And re-adding a server with a different URL rewrote the address while
keeping the credential, so the same token could be sent somewhere else entirely with no
cross-server trick at all: the token really did belong to that server, and only the address moved.

The second is why the first was not enough on its own. A credential now has to belong to the server
it is attached to, and a server that already holds one cannot be re-added at a different address.
Correcting a title or retrying an interrupted add sends the same URL and is unaffected. A server
holding no credential can still be re-addressed, because there is nothing to misdirect. Moving a
server that does hold one means removing it and adding it again with the token the new address is
meant to have, which is the honest description of what has happened anyway.

This matters more than "an administrator could misconfigure something". A stored credential cannot
be read back by anybody, by design: the credentials screen answers that a credential exists and
never what it is. These two shapes were the way around that, so a deployment where somebody has
used them should treat the credentials involved as disclosed and rotate them.

A token also stops outliving the server it was minted for. Re-adding a server without naming a
credential used to clear the pointer while leaving the credential live, and removing a server retires
its token by reading it off that pointer, so a cleared one meant the token survived its server and
could be attached to a freshly created one at any address, where there was no longer a stored address
to compare against. Three ordinary acts in a row and the binding above stopped meaning anything. The
pointer now survives a re-add that names none, removal therefore finds and retires it, and a retired
credential is refused rather than quietly attached to fail on its next call.

Curated servers keep working as they did. Their URL comes from the catalogue rather than the
request, and a per-instance hostname is matched against the vendor's own anchored pattern before
anything is stored, so re-adding one cannot point it at an address of the caller's choosing.

### A configured egress proxy reaches the browser that uses it

`EGRESS_PROXY_DEFAULT` and `EGRESS_PROXY_<BOT>` were documented as the way to give a Bot a stable
outbound address, and Compose passed neither to anything. `docker-compose.yml` named no egress
variable and had no `env_file`, so the shared computer resolved every Bot to no proxy and went out
directly, and under the supervisor the same emptiness meant there was nothing to forward into the
computers it creates.

The failure was silent, which for a setting whose purpose is to give a security team a per-Bot
address for network rules is the worst of the available failures. The stack started, the browser
left by the host, and the Computers screen reported "Leaves directly" because it was reading the
same empty environment.

They now live in `egress.env`, which both the computer and the supervisor are given. A file rather
than more `environment:` entries because `EGRESS_PROXY_<BOT>` is derived from a Bot's id and there
is no fixed set of names to list; a file of its own rather than `.env` because that one holds the
deployment's secrets and the container running a browser and a Bot's shell is deliberately not
given them. It is optional, so a deployment with no proxy is unchanged, and gitignored, because a
proxy URL can carry a password.

**Move these two out of `.env` and into `egress.env`.** In `.env` they reach no process.

### Screens without a conversation stop polling for a Bot that does not exist

Every surface asks which components its Bot holds, and asks again every few seconds so a revoked
grant leaves an open conversation quickly. The Bot it asked about was whichever one the surface
declared — and on a screen with no conversation at all, that was the placeholder id the routing
holder falls back to, which no package registers and the server answers 404 for. An admin page left
open polled a guaranteed miss every five seconds, indefinitely.

Nothing looked wrong. The screen rendered, because an absent grant list and an empty one draw the
same. The cost was the noise: a request log where the same 404 repeats forever is one where the 404
that matters is invisible.

The grant queries now wait for a surface to declare a real Bot, and simply do not run while the
placeholder holds. Conversation surfaces — the Bot page, channels — declare one and are unchanged.

### A rule can be tested against history before it is saved

A boundary was written blind: an administrator typed a CEL rule, saved it, and learned what it
actually matches from the refusals it produced in production. The trail already records every judged
computer action with the same facts the gateway judged it on, so the question "what would this rule
have done" had an answer nobody could ask.

The Boundaries page now has **Test first** beside **Add rule**. The candidate — the current policy
plus the drafted rule — is replayed over recent recorded actions, and the reply names each one it
would have decided differently and the rule that would have decided it. Nothing is saved and nothing
is decided; no audit row is written, because no action was permitted or refused.

Replay, not simulation: the context is rebuilt from the audit row exactly as the gateway built it at
decision time, through the same helpers, so a rule behaves here as it will behave live. The scan is
bounded and biased to recency, and the reply says how many rows it covered.

### A browser refusal names the element again

Every browser context carries a neutral all-empty `mcp` object, so a rule naming `mcp.effect`
evaluates to false instead of throwing. The refusal copy keyed on that object being present rather
than on its contents, so every live browser refusal took the tool-call branch and read
":  on  is blocked" — two empty strings where the element and the page belonged. The tests passed,
because their contexts omitted the field the gateway always attaches.

The branch now keys on the server and tool being named, which a real tool call always has. A refused
click reads "“Submit order” on shop.example is blocked by the rule ..." again, which is what the Bot
relays to the person asking.

### Knowledge searches instead of guessing

A package can say which of its skills each coworker gets, and the fintech example gives Knowledge the
four document skills it ships.

Knowledge is one of three coworkers in the box, described as answering company questions and citing
sources. The skills that would let it do that were seeded attached to nobody, so every clone started
with them paired to no Bot: the per-run narrowing that skills exist for was switched off until
somebody opened the Skills page and made the pairing by hand, in each deployment, again after each
new connector. The pairing belongs with the package, which wrote both files and knows which coworker
it meant them for.

THIS GRANTS NOTHING, which is what makes it safe to seed. A skill is an instruction; what a Bot may
call is its grants, and the offer each run is the intersection of the two. A skill naming a tool its
Bot does not hold loads nothing. Seeding an MCP grant would be the opposite, because those reach a
person's own account, so those stay an administrator's decision and are untouched here.

A redeploy takes back only what the package gave. Grants it made carry `tenant-package`, and a grant
an administrator made through the Skills page keeps their name and survives, because a deploy quietly
undoing a deliberate decision is the kind of change nobody traces back to the deploy that caused it.
A coworker naming a skill its package does not ship is refused at load rather than dropped, the same
as a channel naming an agent that is not there: a typo that silently attaches nothing looks exactly
like working.

### A Bot's computer is no longer on the same network as the database

Compose declared no networks, so every service shared one and reached the others by service name.
One of those services is the container a Bot's shell runs in, and another is PostgreSQL, whose
username and password are in the same file. A shell reaches whatever its container reaches, so a Bot
could open `postgres:5432` and authenticate: the audit trail, the policy store and the agent tables,
from the one container whose job is to run what a Bot asks for. The role Compose creates is the
instance owner, so the trail's append-only trigger was no defence either, being something its owner
can drop.

PostgreSQL and `migrate`, the only service that reaches it by name, are now on a `data` network of
their own. Everything else stays where it was. Nothing changes for a deployment that runs the API
server on the host, which reaches the database through the published port and never used the shared
network for it. **A deployment that runs the server inside Compose has to join that service to both
networks**, which is the one place the two are meant to meet.

The published port is now on loopback, as every other port in that file already was. Taking the
database off the Bots' network removes the name, not the address: a container's default gateway is
the host, and a port published on every interface answers there. From inside the computer container,
the gateway on `5432` accepted a connection and began authenticating as `openbot` on `openbot`, with
the password in the same file. **A deployment that reached the database from another machine over
this port has to reach it another way**, which is what publishing it on every interface was doing.

This does not reach back in time. A deployment that has been running with the two on one network
should assume a Bot could have read or written the database, and look at the trail with that in
mind.

### A credential in an MCP server address is refused in the query and the fragment too

Refusing `https://user:token@vendor.example/mcp` closed the userinfo spelling of a credential in the
address and left the two obvious ones open. `?token=`, `?api_key=` and their neighbours were still
accepted, and the address is stored and named in the trail exactly as given: audit redaction keys on
the field name, `url` is not a sensitive one, so the secret was written to `mcp_servers` and to an
append-only audit row in clear text. That is the same disclosure the userinfo rule exists to prevent,
one character away.

A parameter whose name reads as a credential is now refused, in the query string and in the fragment,
and the refusal points at the token field without repeating what was typed. The name is read rather
than matched against a list, so `?auth_token=`, `?x-api-key=` and `?X-Amz-Signature=` are refused
alongside `?token=`: a rule that only catches the spellings somebody thought of reads as a guard
while behaving like a gap. The test is on the parameter name rather than on the presence of a query,
because vendors route and version with parameters and a floor that refused every one of them would
be one an operator works around instead of with. `https://mcp.example.com/mcp?workspace=acme&version=2`
is unaffected, and so is an ordinary fragment. A credential written into the *path* is still
accepted: it is indistinguishable from a route, and at least one hosted provider addresses servers
that way. **A deployment where somebody has put a credential in an address should treat it as
disclosed and rotate it**, for the same reason as before: the audit row cannot be deleted.

`metadata.goog` is refused too. It is Google's own short name for the metadata server, published
beside `metadata.google.internal`, and it carries a dot and none of the suffixes this check lists, so
it read as an ordinary vendor name. The long spelling was only ever refused incidentally, by the
`.internal` rule. Both are now named, so the address this check was written for is refused on purpose
rather than by luck.

### A curated MCP server is pointed at its own kind of credential too

Adding a server by URL was made to check which credential it is being pointed at. Adding one from the
catalogue, the other half of the same screen, took the same field from the same request and stored it
unread, so a credential of any kind could be attached to a curated server and spent by the refresh
that runs before the add returns.

Worth being plain about the reach, because it is narrower than the path beside it. The column is a
foreign key, so an id naming nothing was already refused by the database, and the one entry in the
catalogue is reached with each person's own Google account, whose OAuth client is registered through
its own call and sent to an address pinned in code. Nothing could be delivered to an address a caller
chose. What was reachable was a credential of the wrong kind being accepted and spent on behalf of
somebody who never agreed to it, and a malformed id arriving as a database error rather than as a
refusal.

The rule now comes from the entry: a server the deployment holds one token for takes that token, and
a server answered as the person asking takes no credential when it is added, because its client
arrives through the call that mints it. Both add paths ask the same question in the same words, so a
credential that does not exist and one of the wrong kind are still refused identically and the
endpoint cannot be used to ask which ids are real. Adding a curated server the way the admin screen
does is unchanged.

Adding a curated server that is already there no longer clears the credential it points at. The
column holds the OAuth client that registering one put there, and re-adding the server to change an
instance host said nothing about that client, but cleared it anyway: the credential row was left
behind with nothing pointing at it and nothing to revoke it, and everybody who had connected their
account was told the deployment has no client registered. A re-add that names no credential now
leaves the one that is there alone.

### Name the private addresses an agent may live at

Refusing `AGENT_COMPUTER_ALLOW_PRIVATE_HOSTS` in production closed a hole and took something with
it: bring your own agent is a headline capability, a company's own agent legitimately lives at an
internal address, and the only way to reach one was to lift the floor for everything. Telling people
to set that flag is exactly the advice that made it dangerous.

`AGENT_ENDPOINT_ALLOWED_HOSTS` names addresses instead. A comma-separated list of hosts, each
optionally with a port: `agents.internal` covers any port on that host, `10.0.0.42:9000` pins that
one. A deployment sets this and leaves the floor where it is.

It is narrow on purpose:

- **Agent endpoints only.** Browsing is not widened. A page can steer a Bot somewhere; an operator
  naming an address they run is a different act from a Bot following a link to it.
- **Exact matching.** No wildcards and no suffixes. A list written with a `*`, or written as URLs, is
  refused at startup with the entry named, rather than quietly never matching.
- **The never-allowed addresses stay never-allowed.** Cloud metadata is refused before the private
  rule is reached, so naming it changes nothing.
- **Every hop, not just the first.** A named address is reachable wherever it appears and an unnamed
  one is refused wherever it appears, so a redirect is not a way around registration.

Unset means none, which is what every deployment has today.

### A custom MCP server can only be pointed at its own token

Adding an MCP server by URL takes a credential id alongside the address, and the add is what spends
it: the tool refresh that runs before the call returns decrypts whatever that id names and sends it
to the address in the same request. Nothing checked which credential it was, so an administrator
could name any row in the vault, including one person's connector token, and have that person's
token delivered in clear text to an address of the administrator's choosing, before any Bot or grant
was involved. The credentials screen lists every row's id and, for a connector token, the person it
belongs to, so choosing one was a single read.

A custom server now has to be pointed at a credential of its own kind, the deployment's token for
that server. A person's connector token and the deployment's OAuth client are both refused, for the
same reason `POST /api/admin/credentials` already refuses to create either by hand: spending one
here uses a credential on behalf of somebody who never agreed to it. A credential that does not
exist is refused in the same words as one of the wrong kind, so the endpoint cannot be used to ask
which ids are real.

The field is unchanged for the case it exists for, and nothing changes for a server added through
the admin screen, which mints a token and points at the one it just made. If a deployment has a
custom server pointing at a credential of another kind, adding it again will now be refused, and the
answer is to give the server its own token.

### A failed action is recorded the same way it was decided

An action the policy allowed and the computer then failed is recorded twice, once for the decision
and once for the outcome, so the trail can tell an action that happened from one that was permitted
and did not. The second row was leaving out the command and the key that the first one carried.

A shell command that failed part-way therefore said a Bot had run something without saying what, in
the row somebody reading an incident reaches for first. The same omission picked the wrong element
branch, so that row also claimed the command had been looked for in the page snapshot and not found
— a page element a shell call never had. A failed file write kept its path throughout and is
unchanged.

Both rows now carry the same subject. Nothing about the boundary moves: the policy decided on a
complete context before and after, and no action is permitted that was not permitted before.

### Upgrading

**A deployment that sets `AGENT_COMPUTER_ALLOW_PRIVATE_HOSTS=true` with `NODE_ENV=production` no
longer starts.** Remove the line and it starts again. Nothing else needs changing, and a deployment
that never set it is unaffected.

The switch lets a Bot reach addresses inside the deployment's own network — `10.0.0.5`,
`192.168.1.1`, `127.0.0.1:5432`, a link-local address — and it does that in two places, not one:
browsing, and the endpoint a Bot may be registered against. It exists for a laptop, where the
services a Bot is asked to look at are the ones running beside it.

The reason this is a refusal rather than a warning is how a deployment came to have it. `.env.example`
shipped the line on, and copying that file is the ordinary way an environment gets filled in, so the
path to a hosted deployment reaching its own network was not forgetting to set something, it was
inheriting something. It now ships commented out, which means a laptop that wants the old behaviour
uncomments it and everything else arrives without it. Under any other `NODE_ENV` the switch works
exactly as before, with a warning at boot saying it does not travel.

**The one-container image shipped with the switch on, and no longer does.** It set both
`AGENT_COMPUTER_ALLOW_PRIVATE_HOSTS=true` and `NODE_ENV=production`, so the image really did run
with private-host browsing enabled. Two things that worked there stop: a Bot browsing a private
address such as an intranet page, and registering a coworker at a private endpoint like
`http://10.0.0.20:8000/ag-ui`. Because the image bakes in `NODE_ENV=production`, there is no
override — a deployment that needs either of those wants the compose setup or its own image rather
than the all-in-one. The image continues to start, and everything else in it is unchanged.

The cloud metadata addresses — `169.254.169.254`, `metadata.google.internal`, and the IPv6 and
NAT64 spellings of them — were refused whatever this switch said, before and after. That floor has
not moved. What changed is that it is no longer the only thing left standing in a production
deployment that copied the example.

### The supervisor answers on loopback, not on every address the host has

The supervisor's port was published without an interface in front of it, so it bound every address
the machine had and answered anything that could route to it. This is the service that holds the
Docker socket, so reaching it is root on the host by way of four verbs, and `SUPERVISOR_TOKEN` is a
shared secret rather than a network boundary. The documentation already said not to expose it
outside the deployment network; the compose file did.

It is now published on `127.0.0.1`, like the computer's own port and the two Bots'. If you reach the
supervisor from another machine, that stops working and it was the thing worth stopping: put the
caller on the host, or run the server inside the compose network, where it reaches the supervisor as
`supervisor:4300` and never uses the published mapping at all. `SUPERVISOR_PORT` still chooses the
host port.

Nothing changes for a default deployment. `scripts/start.sh` already reached it on `localhost`.

### An agent's address is checked where it ends up, not only where it starts

`checkAgentEndpoint` decides whether this deployment will dial an address, and the request was then
handed to a fetch that followed redirects. The checked address and the dialled address were the same
address only while nobody redirected. An agent answering `307 Location: http://169.254.169.254/` put
the server on its own cloud metadata endpoint, on every run rather than once.

Every hop is now checked before it is followed, capped at three. Redirects are still followed,
because a deployment that puts its agent behind one has done nothing wrong, and each destination has
to be somewhere registering it directly would have been allowed to reach. The stored address is
checked before it is dialled too, which is the one address a check reading only `Location` headers
never looked at.

A hop that leaves the host the request was authorised for arrives with nothing that proves who we
are. The customer's key was given to us for their host, and this deployment's signed run assertion
names the Bot and the person and can spend their grants, so both stop at that boundary and do not
come back if the chain returns. A scheme upgrade to the same host and port keeps them.

Refusals are now on the audit trail as `agent.dial_refused`, with the address and the reason. A
refused run already told the person what happened; nothing told the deployment, and an agent that
has quietly started redirecting somewhere it should not is worth being able to count.

### A connector says which of its granted tools it no longer offers

A grant names `serverId/toolName`, and a Bot is told about a tool only when the grant and the vendor's
current tool list agree — so a grant on a tool the vendor has stopped listing reaches no model. That
is a property of what the vendor advertises today rather than of the grant, and nothing said it was
happening: the plugins page built its grant list from the advertised tools, so such a grant appeared
nowhere at all. The one screen an administrator reads to answer "what may this Bot do" was quietly
leaving some of the answer out.

A connector's page now has a "Held but not offered" section listing them, with how many Bots hold
each, and a refresh that leaves any behind writes an audit row naming the refs and the Bots. The
grants themselves are untouched: a tool the vendor starts listing again is offered again, and revoking
stays a decision somebody makes rather than a side effect of a vendor's bad afternoon.

Nothing changes for a connector whose grants all match its tool list, which is the normal case — the
section is not drawn and no row is written.

### Opening a new chat no longer logs a server error

A thread id is minted before the thread exists — the platform creates it on the first run — so reading
history on a brand-new conversation asks about a thread nothing has heard of yet. The platform answered
404, the runtime reported that as `500 Failed to fetch thread messages`, and every new chat left one in
the log with a stack trace behind it. Nothing was visibly broken, because the browser only reads a
history it got a 200 for; what was missing was any way to tell a thread that does not exist yet from a
history store that is down.

A thread the platform does not have now reads as having no messages. A 404 and only a 404: a 500 stays
a 500, because an outage answered with an empty history would tell the browser the conversation is gone
and invite somebody to start it over.

### Reconnecting a live screen no longer stops the screen you just reconnected

A Bot's screen allows one viewer, and opening a second `/stream` replaces the first. The replaced
socket is left open, because it belongs to a client that may still be using it, so on an ordinary
reconnect, where the browser opens the new connection before dropping the old one, the old socket
closed after the new one was already casting. Closing it stopped the session's viewer without asking
whether the closing socket was the one casting, so it stopped the replacement.

Both halves were silent. The screen stopped updating, and anything typed afterwards was dropped
without a word, because the input path looks for a viewer before it looks for anything it can report.

A close now stops casting only when the socket closing is the one that was casting.

### A sidebar channel row can be pinned or deleted

Right-click on a channel in the sidebar and a menu opens with two entries: Pin channel and Delete
channel.

Pin is held per member rather than per channel, so pinning one holds it at the top of your own
roster — newest first among pinned channels — and leaves every other member's roster unaffected.

Delete is confirmed in a dialog first, and it is soft. The channel disappears from every member's
roster and from a direct fetch of it, while the row, its transcript, and its Intelligence thread all
survive. That disappearance is live, not just on next load: every member's open tabs drop the row as
the delete lands, and a tab parked on the channel itself is sent home. The deletion is audited as its
own `channel.deleted` row. A channel the deployment package defines is refused, with the reason
named. Recovery today is clearing `channels.deleted_at` in the database directly; there is no restore
control in the product.

The deployment gains two nullable columns, via migration `0016`.

### An MCP server address that points inside the deployment is refused in three more spellings

Adding an MCP server by URL is checked before the address is stored, because that form is otherwise a
way to point the deployment at its own network. The check compared the literal hostname, and three
spellings of an address it means to refuse were getting through.

A trailing dot is the root-anchored form of the same name and reaches the same place, but it changed
the string enough that every rule missed it, so `https://localhost./`, `https://printer.local./` and
`https://metadata.google.internal./` were all accepted. `kubernetes.default.svc`, which is how a
service is addressed from inside a cluster, carries dots and none of the listed suffixes, so it read
as an ordinary vendor name.

The third is worth acting on rather than just noting. A credential typed into the address itself,
`https://user:token@vendor.example/mcp`, was accepted, and the address is stored and named in the
trail as given. Audit redaction works on field names and `url` is not one of the sensitive ones, so
the token was written to `mcp_servers` and to an audit row in clear text. The trail is append-only by
design, so that row cannot be deleted afterwards: **a deployment where somebody has done this should
treat that credential as disclosed and rotate it.** The address field now refuses a credential and
points at the token field instead.

A deployment that reaches its MCP servers by ordinary vendor hostnames sees no difference.

### One unreadable turn no longer takes a whole conversation down

Restoring a thread cast whatever the history store held straight to messages and handed it to the
transcript. A turn stored in a different shape — a tool call written `{id, name, args}` rather than
AG-UI's `{id, type: "function", function: …}`, which interrupted runs have produced — reached a
renderer that read `toolCall.function.arguments` and threw, so a single bad turn made the whole
conversation unopenable rather than that one message unreadable.

Each stored turn is now parsed against the schema AG-UI ships, and one that does not parse is left
out instead of being drawn. Checked where history enters the app rather than in one renderer, so
every surface that reads a transcript is covered by the same check.

**A turn that is left out is said out loud.** The conversation shows a line above it naming how many
earlier messages could not be read, because a record people read back must not have a hole in it that
nothing accounts for — a turn that silently disappears reads as one that was never sent. Multimodal
content and every well-formed tool call are unaffected, and a history that cannot be read at all
still opens the composer rather than blocking it.

### Refreshing no longer flashes white before the theme arrives

A person with the dark theme selected saw a white frame on every reload. The stored preference was
read early enough, but it was applied one paint too late: the browser had already drawn a frame
against the light palette by the time the app got to it. The document now decides its theme before
anything is drawn.

The browser was also drawing its own surfaces — scrollbars, form controls, the overscroll area —
light under a dark app, for the whole session rather than for a frame. Both themes now declare which
one they are, so those match too.

No configuration changes and nothing is stored differently; a deployment that was already on the
light theme sees no difference at all.

### `start.sh` refuses a port that answers but is not OpenBot

The startup checks asked whether a port answered, and treated that as proof the port belonged to this
stack. Those are not the same claim. Any single-page app serves its index.html for every path it does
not recognise, so an unrelated dashboard on a default port answers `200` to `/api/capabilities` as
readily as this server does.

The cost was not a wrong answer, it was a wrong answer three stages later. `require_free_or_ours`
reported "already up", so the server was never started; `wait_for` then printed a green
"server ready"; and the run failed at stage 3 inside `json.loads`, parsing that stranger's HTML. The
error names `char 0`, which reads like an empty response rather than a `<`, so the visible symptom
pointed nowhere near the port.

Each surface is now asked for something only it can produce: a `licenseStatus` field for the server,
its own `<title>` for the app, `/health` for the compose services. When a check gives up it says
whether the process failed to start or the port belongs to something else.

The root cause was in `.env.example`, and is fixed there too. The server reads `PORT`, this script
reads `SERVER_PORT`, `docs/configuration.md` documents `SERVER_PORT` as the setting, and only `PORT`
shipped. Moving the server by editing that one line left the script still looking at 3001. Both names
are now present, next to each other, saying they have to agree.

**A run may now stop where it used to continue.** That is the point: it stops at the port that is
wrong, naming it, rather than several steps later on a parse error.

### `docker compose up -d` configures the same stack `scripts/start.sh` does

`SUPERVISOR_TOKEN` and `COMPUTER_TOKEN` defaulted to the empty string in `docker-compose.yml`, so
which stack you got depended on how you brought it up. `scripts/start.sh` resolves both to their
`openbot-dev-*` defaults and exports them before calling compose. A plain `docker compose up -d` —
which this project's own shutdown notes tell you to use — passed an empty string instead.

`agent-computer` refuses to start without one, so that half failed loudly. The supervisor half was
the quiet one: the server kept the token it started with while the supervisor held an empty string,
and every call between them was refused at the door.

Both now carry the same defaults `start.sh` applies, as `COMPUTER_IMAGE` already did two lines down.
A value set in `.env` still wins, and a deployment should set one.

## 0.0.4

### A click citing a ref this deployment cannot resolve is refused

A Bot acts on a page by citing a ref from a snapshot, and the server turns that ref back into the
element before the boundary judges it. When the lookup failed, the action went ahead anyway with the
element half of the decision left empty — so a rule like "never click anything named submit" was not
declining to match, it was never shown the element, the shipped default permitted, and the click
landed on whatever that ref points at now.

The computer's own staleness check does not cover this. It compares a citation against its own
counter, so it catches the cases where the two disagree; the case that bites is the one where the
computer is content and only this deployment is out of step, which is what restarting a computer
under a stored snapshot leaves behind. The same click on the same button under the same policy was
refused before a redeploy and carried out after it.

A citation this server holds a snapshot for and cannot resolve is now refused, and the person is told
to take a fresh snapshot. Actions that name no element — scrolling, a page-level keypress, a shell
call, a file read — are untouched, and a computer this deployment holds no snapshot for still has its
citation forwarded, because there it is the only party that can answer. The refusal is raised after
the decision row is written, so an action somebody tried to take still appears on the trail.

**A deployment may see refusals it did not see before.** That is the point: those are the actions that
were being carried out without the boundary seeing what they touched. A Bot that meets one takes a
fresh snapshot and continues.

### A package ships its skills, so tool selection works on a clone

Tool selection narrows a Bot's tools to the ones its matching skills declare, and a deployment starts
with no skills at all. There was no `skills.yaml`, nothing seeded any, and nothing ever created one
— so on every fresh clone there was nothing to match against and the narrowing never switched on.
Left to a screen it would have stayed that way until somebody sat down and mapped tools to skills by
hand, in each deployment, again after each new connector.

A tenant package may now carry `skills.yaml`. Each skill has a slug, a title, a summary, its
instructions, and the `serverId/toolName` refs it needs. They are seeded on boot as deployment
skills, everybody sees them in the `/` menu, and connecting a connector is the only step left.

`skills.yaml` is optional, so every existing package loads unchanged and ships no skills. A package
may declare tools for a connector nobody has added: an unknown ref sits inert, because the offer is
still intersected with the Bot's grants. Naming a tool in a package grants nothing, exactly as
before.

A skill somebody wrote in the deployment keeps its name. If a package ships a slug a person already
took, theirs stands, the package loses that one, and the deployment starts — a name is not worth
refusing to boot over.

The example package ships four: `/find-a-document`, `/whats-changed`, `/who-owns-this` and
`/check-a-claim`.

### The tools a skill needs can be picked where the skill is written

A package's skills arrive with their tools declared. A skill somebody writes here could not: the
`tools` field existed on the save endpoint and on no screen, so a skill written in the product declared
nothing, and the only way to change that was to call the API by hand. Writing or editing a skill now
lists the tools of every connected server, grouped by server, with the ones that change something
marked.

Picking a tool here is not granting it. The offer is still intersected with what the Bot was granted,
so a skill naming a tool its Bot does not hold selects the skill and loads nothing — which is why
anybody may write a skill while connecting a server stays an administrator's decision. The screen says
so, next to the choice.

A tool the skill names that no connected server offers is shown too, under its own heading, rather
than left out. A package ships skills declaring tools for connectors nobody has added yet, and a
skill outlives the server it was written against, so a screen that drew only what matched was
stating part of the declaration as though it were all of it.

## 0.0.3

### A Bot is offered the tools its message needs, not every tool it holds

A model chooses the right tool reliably out of about ten and unreliably out of thirty, and it fails
quietly: it calls a plausible neighbour, or calls nothing and answers from what it already knew. Two
connectors is enough to cross that line, so a Bot holding more than twelve tools is now offered, for
each run, the tools of the skills that match the message.

Skills already declare the tools they need. That declaration is now what the offer is built from:
the deployment asks its own model which skills a message needs, and the Bot gets those skills' tools
plus every granted tool no skill has claimed. Nothing here can widen a Bot: the offer is intersected
with the grants, so naming a tool in a skill still grants nobody anything.

Nothing changes for a deployment that has not declared tools on any skill, or whose Bots hold twelve
tools or fewer. Those Bots are built exactly as before, with no extra model call.

There is a new audit event, `mcp.tools_discovered`, written before the run. It says how many tools
were offered out of how many granted, and why: the skills chosen, or that nothing was declared, or
that the choice could not be made. It answers "why did it call that", and the harder question, "why
did it not call anything at all" — which until now left no trace.

### The intent router works again behind a gateway

`OPENAI_BASE_URL` is documented ending in `/v1`, and the router appended `/v1/chat/completions` to
it, so every call went to `/v1/v1/chat/completions` and 404'd. The router reads a failure as "not
sure" and falls back to the default coworker, so on any deployment that set the variable — a
gateway, a proxy, a self-hosted model, which is the only reason to set it — untagged messages
silently stopped being routed and nothing said why. The version segment is now added only when the
configured URL does not already carry one.

## 0.0.2

### Upgrading

`AGENT_TOOL_TOKEN` is generated for you on a laptop. `scripts/start.sh` mints one and writes it to
`.env`, the way it already did for `MANAGED_AGENT_TOKEN`. Without it no Bot could call a tool back
through the deployment, which is the correct default for a deployment and made every MCP tool dead
on arrival on a fresh clone. A value already set is kept, and `.env.example` still ships it empty,
so a deployment not using `start.sh` is unchanged and still fails closed.

`start.sh` also stops skipping work for services that are already answering. A Bot container is now
handed to `docker compose` on every run and the server is restarted when this run minted a secret,
because answering says a process is alive and not that it still agrees with the deployment. The cost
is that a run which rebuilds an image recreates the Bot containers, about five seconds; `supervisor`
already behaved this way.

Two configurations now refuse to start:

- A provider configured with no `INITIAL_ADMIN_EMAILS`. Set it to at least one address.
- No provider at all and no `OPENBOT_SINGLE_USER=true`. Configure a provider, or set that to say you
  meant a deployment where every visitor is one administrator. This no longer depends on `NODE_ENV`,
  which is unset by default and so let exactly the dangerous case through. A deployment already
  running open needs the line added before it will start again.

Registering an OpenID Connect provider needs every host in its discovery document in
`TRUSTED_ORIGINS`, not only the issuer. Better Auth 1.7 checks each endpoint it finds, so a Google
issuer also needs `oauth2.googleapis.com` and `openidconnect.googleapis.com`. Registration is
refused with the untrusted host named.

A Bot id may now contain only letters, digits, hyphen and underscore, and must start with a letter or
digit. The same rule container and volume names have always followed. A deployment whose
`COMPUTER_BOT_ID` breaks it refuses to start and says so, rather than answering 400 to everything.

`AUDIT_RETENTION_DAYS` is new and unset, which keeps the audit trail forever, as before. Set it to a
whole number of days to have old rows removed.

The local document index and the old connector tables are dropped by migration. `documents`,
`chunks`, `document_acls` and the four connector-bookkeeping tables are removed and their rows go
with them; this cannot be rolled back. A deployment that had been syncing into the local index loses
that copy, which is the point: answering now goes through a live system's own search.

**An MCP server pointed at a credential that no longer exists loses the pointer.** `mcp_servers`
now names its credential with a real foreign key, where the column was `text` against a `uuid`
primary key with nothing checking it — so a deployment is allowed to be holding a pointer to a vault
row that was deleted underneath it, and the screens read as though the server were still configured.
The migration clears those before adding the key, because it cannot add it otherwise. If this
happens, that connector correctly reports having no credential and an administrator registers it
again; nothing else is affected, and a deployment with no such pointer sees nothing.

**The old Google Drive connector is gone, and it is not the new one renamed.** It configured a
service account with domain impersonation and had the worker sync documents into a local pgvector
index guarded by our own ACL rows, so every person got the same answer computed from what one
credential could see, and revoking somebody's access left a cached copy of their documents behind.
`/admin/connectors` and its two screens, the connector catalogue and admin service, the sync
persistence and the worker's connector runner have all been removed. A deployment that was syncing
this way stops syncing and should enable the new connector at `/admin/plugins/google-drive`, where
each person connects their own account.

`knowledge.yaml` is still parsed and still refused when malformed, because it is part of the
deployment-package contract. Its `sources:` are now read by nothing.
`MANAGED_AGENT_AG_UI_URL` is no longer required to start. The one-container image does not carry a
Bot, so requiring it registered the shipped Risk Analyst against a host that was not there and every
conversation with it failed. Leave it unset for that image. A laptop `scripts/start.sh` still points
it at `agent-langgraph`. A URL with no `MANAGED_AGENT_TOKEN` still refuses to start; a leftover
token with no URL is ignored.

A `.env` copied from an older `.env.example` still has `MANAGED_AGENT_AG_UI_URL=http://localhost:4201/ag-ui`.
Unset it before `docker run --env-file .env`, or the coworker comes back.
The built-in Bot refuses to start without `OPENAI_API_KEY`. It used to start, report healthy, and
then fail every conversation, so a missing key looked like a working deployment. The LangGraph Bot
already refused the same way.

Sessions survive and nobody signs in again.

### Changed

- **This deployment does not search documents itself.** A Bot answers from a live system by calling
  that system's own search as the person asking, so the vendor decides what they may see and there is
  no second copy of anybody's documents here to keep in step, to secure, or to leave behind when
  somebody is removed. The local index that was being filled — `documents`, `chunks` and
  `document_acls` — and the connector that filled it have both been dropped. Retrieval over
  a copy of a customer's corpus is not a thing OpenBot does.

### Added
- **A skill can say which tools it needs.** `POST /api/plugins/skills` takes a `tools` list of
  `serverId/toolName` references, stored against the skill and returned with it. This is the unit
  tool retrieval will select over: a model picks a skill from its summary, and the skill says
  what to load. **It grants nothing.** A skill naming a tool a Bot was never granted still cannot
  call it, which is what keeps writing a skill open to anybody rather than to administrators
  only. A reference naming no tool this deployment has seen is refused when the skill is saved,
  so a typo is an error where it was written. Leaving the field out of a save leaves whatever was
  declared before, so nothing that predates it clears a declaration; sending an empty list is how
  a skill stops asking. Nothing consumes these yet — selection is the next piece, and until it
  lands a deployment behaves exactly as before.
- **A message with no `@` goes to the coworker it is for.** Typing without naming anyone used to
  reach the default coworker; to get a specialist you had to `@` them. Now an untagged message is
  routed to the coworker whose purpose matches it, chosen against each coworker's own description by
  the deployment's own model, before the channel is pinned. It is named, not silent: the channel
  header is the coworker it went to, and a `channel.routed` row records the choice, the reason, and
  the candidates it chose between (never the message itself). `@` still wins as an explicit override
  and skips routing entirely. If the router is uncertain or unreachable, it falls back to the same
  default the composer always used, and says so, rather than misroute or drop.

- **A Bot can answer from Google Drive, as the person asking.** Ask a Bot a question whose answer is
  in a document and it answers from the live file rather than from an index, citing a link that opens
  it. A Bot granted these tools reads Drive on the asker's own grant, so two people asking the same
  question get the answers their own accounts can see, and neither sees the other's documents.
  Read-only: the scope requested is `drive.readonly`, so a write is refused by Google before this
  deployment has to. Nothing is cached — the refresh token is stored and an access token is minted
  per call, so revoking access at Google takes effect on the next one rather than when a cache
  expires.

  Setting it up takes two people and neither can do the other's half. An administrator registers a
  Google Cloud OAuth client and enables the connector at `/admin/plugins/google-drive`; each person
  then connects their own account, and there is deliberately no endpoint for an administrator to
  connect one on somebody's behalf. The redirect URI has to match what is registered character for
  character, and the connector page states the exact string to paste, because a mismatch fails at
  Google with a message that never mentions OpenBot. See
  [docs/plugins/google-drive.md](docs/plugins/google-drive.md) for the whole setup and for what each
  failure means.

  **Disconnecting is not built yet.** The account page says so and points at Google's own third-party
  access settings, which is what withdraws it today.
- **Each tool a connector offers has its own screen**, at `/admin/plugins/<connector>/tools/<tool>`,
  with a switch per Bot. The connector page previously drew a button per Bot inside every tool row,
  which is a control per Bot per tool stacked in one list, and grew without bound as Bots were added.
- **Connected accounts**, at `/settings/connected-accounts`. What a Bot may read as you, and the
  scope the vendor actually granted rather than the one that was asked for.
- **A tool result that found nothing says so.** An empty result used to reach the model as an empty
  string, which reads as "the tool had nothing to say" rather than "there is nothing there" — and a
  model closes that gap from memory, which for a knowledge connector is the failure worth preventing.
- **The shipped Knowledge Bot answers from the tools it has.** Its instructions in
  `examples/fintech` told it to say no source was connected, which was honest when none could be:
  the connector this replaces had been removed and nothing had taken its place. With a connector
  granted it became the opposite of honest — the Bot called a tool, was handed a file listing, and
  said it had no access anyway. It now reports what its tools return, says so plainly when it has no
  tool or a tool reports a problem, and does neither of the two things worth forbidding: answering
  from its own memory as though it came from a source, or claiming to lack access to something a tool
  has just returned. A deployment with its own tenant package is unaffected.
- **`mcp.call_failed`.** A call this deployment permitted and the vendor did not complete now leaves
  a row of its own, carrying the vendor's own sentence. `mcp.call_succeeded` was written before the
  network call rather than after, so a call that died at the vendor recorded success and the Admin
  page agreed with it.
- **Releases are cut by a workflow, not by hand.** `Create release PR` bumps the version and promotes
  `## Unreleased` to a numbered section; merging the pull request it opens is what publishes. Merging
  builds and pushes one image to `ghcr.io/copilotkit/openbot`, signs a build provenance attestation
  for its digest, tags the commit and creates the GitHub Release with `container-images.json` so a
  deployment can name an exact digest rather than a tag somebody could move. See
  [docs/releasing.md](docs/releasing.md).
- **CI now runs the thing it ships.** Two checks were added. `migrations` refuses a schema change
  with no migration written for it, and a snapshot that has drifted from the schema. `image` builds
  the container, boots it with embedded PostgreSQL, and fails if it does not answer or if a
  supervised service is respawning. A single `verify` check covers every job, so branch protection
  needs one entry. The same checks run again against the release commit when a release is published,
  so they gate the release rather than the proposal for one.
- **Sign in with Google, Microsoft or Okta.** Any one of them turns sign-in on; configure several
  and the sign-in screen offers each, on matching buttons carrying each provider's own mark.
  `INITIAL_ADMIN_EMAILS` says who is an administrator. It is required whenever a provider is
  configured, because nothing else grants the role, and it is now a floor rather than a one-off:
  an address it names is made an administrator at every sign-in, so adding somebody to the list
  works even after they have already signed in.
- **SAML and OpenID Connect, registered while running.** `/admin/identity-providers` takes the
  metadata a company's identity team supplies and registers their own IdP. Somebody then types their
  email address on the sign-in screen and the domain decides which provider they are sent to, so a
  company mid-merger can run two. Registering, changing or removing one is administrator-only, which
  the upstream plugin does not require: it guards those routes with a session, and anybody who could
  reach them could register a provider for a domain and mint themselves colleagues.
- **A People screen.** `/admin/people` lists everybody who has signed in, with the provider they came
  through and when they were last here, and lets an administrator promote, demote, or remove
  somebody. Removing ends the session they are using and stops the next sign-in, keyed on the
  address so signing in again through the provider does not quietly create a new account. Every
  change is on the audit trail. Somebody named in `INITIAL_ADMIN_EMAILS` cannot be demoted or
  removed here, and nobody can do either to themselves.
- **One container that runs the whole thing.** The root `Dockerfile` builds an image carrying the
  app, the API, a Bot computer, and optionally PostgreSQL, supervised together. Point `DATABASE_URL`
  at a database you already run and the built-in one never starts; leave it unset and the container
  is self-contained. See [docs/deployment.md](docs/deployment.md) for the measured minimum sizes and
  the platforms it has been run on.
- **Bots can run commands.** `computer_run_command` runs a command in the Bot's `/workspace`, so a
  Bot can install a tool, unpack what it downloaded, or run what it was asked to run instead of only
  driving a browser. Governed like every other action: the policy decides, the audit row is written
  first, and a rule can refuse a shell outright with `intent == "run_command"` or refuse particular
  commands. The command is recorded; its output is not.
- **The audit trail shows the command.** A command row names what ran, the way a file row names the
  path, rather than reporting an element it was never about.
- **`COMPUTER_SANDBOX=on`** turns on Chromium's own sandbox where the host permits user namespaces.
  Which way it went is printed at start-up either way.
- **New chat.** The direct Bot chat has a button that starts a fresh conversation, which it had no way
  to do before: the thread was minted once and remembered for that Bot forever, so the only way out
  of a conversation was to clear the browser's storage by hand.
- **You can watch what a Bot is doing, not only what it is looking at.** The screen answered half the
  question: a Bot spending two minutes in a terminal showed a blank browser and one grey line per
  command, with the output nowhere. A command line in the transcript now opens to show what it
  printed, its exit code, and whether it was cut short or stopped. Beside the screen there is an
  Activity tab carrying every command, file read, file write and listing as they happen, newest
  first, with a count on the tab so a Bot working away from the browser is visible without switching
  to it. A saved file shows its path and size, never its contents. This is a live view of the open
  conversation; the record is still the audit trail.
- **Sign-in is on the audit trail.** Rows for signing in, for being refused, and for the configured
  administrator list granting somebody the role. Two questions had no answer before: who granted
  themselves administrator by editing `INITIAL_ADMIN_EMAILS`, and whether somebody just removed had
  ever been here, since removing them deletes the sessions that were the only evidence. A trail that
  is unavailable never blocks a sign-in.

### Fixed
- **A ref could resolve against a page from a computer that no longer existed.** The generation a
  computer stamps on a snapshot is unique only within one run of it, so a replaced container counts
  from one again and a ref the model is still holding matches a row nothing has overwritten. The
  policy then decides on an element from a dead page, and the audit row names it. Wiping a computer
  cleared the row for that reason and was the only thing that did; replacing one whose image changed
  did not, and the server was never told. A snapshot now carries which run of the computer took it,
  refs from an earlier run resolve to nothing, and the first snapshot of a new run replaces the old
  row however low its generation.
- **A migration stamped in the future silently swallowed the next one.** Drizzle runs a migration only
  when its journal timestamp is later than the newest one the database has recorded, so a migration
  stamped ahead of real time raises that ceiling and every migration written after it is skipped
  until the clock catches up. `drizzle-kit migrate` reports success the whole time. One migration was
  hand-written a day into the future and did exactly that to the next one to arrive: the table was
  never created, and the only sign was an integration test failing on a relation that did not exist.
  The timestamps are corrected, an older inversion between two earlier migrations is corrected with
  them, and the journal is now checked by a test, because nothing else in the build would notice.
  **If you ran a build between these, your database has the wrong ceiling recorded and will skip the
  next migration.** Repair it with
  `update drizzle.__drizzle_migrations set created_at = 1787359000000 where created_at = 1787444747113;`
  or start from a fresh database, where migrations all run in one pass and ordering cannot bite.
- **Every Bot ran a model two generations old, and it was costing tool calls.** The example package
  shipped `gpt-4.1` as the default for every built-in Bot. Asked to open a page behind a sign-in,
  those Bots answered "would you like me to prompt you to sign in?" and called nothing, three times
  out of three, while the prompt forbids that sentence in as many words. On `gpt-5.6-terra` the same
  question produces the tool call first try, so the package now runs `gpt-5.6-terra`. It is a
  default, not a commitment: `model.yaml` still decides.

  The Bots that answer over AG-UI stay on `gpt-5.5`, each for its own measured reason. The framework
  Bot answers nothing at all on `gpt-5.6-*` through the Responses API — `RUN_STARTED`, then
  `RUN_FINISHED`, no text — and the hand-written one cannot use function tools on
  `/v1/chat/completions` with a 5.6 model unless reasoning is turned off, which is the wrong trade
  for a Bot whose job includes deciding when to ask a person for help. It refuses to start on such a
  model now rather than failing one silent tool call at a time. Where a 5.6 model is set deliberately,
  the Responses API is switched on for it automatically, because a deployment that set the model and
  did not know about that switch got a Bot which started, looked healthy, and failed on its first
  tool call.
- **A Bot browsed to a vendor this deployment already connects to.** A Bot holding no grants was told
  nothing about connectors at all, so it treated a connected vendor as an ordinary website: asked
  about Google Drive it opened `drive.google.com`, met a sign-in page, and asked the person to sign
  in to an account the deployment had already connected. Every Bot is now told which vendors exist
  here, held or not, and says plainly which one it has not been granted rather than reaching for the
  browser.
- **A conversation was destroyed by a declined take-the-wheel.** A Bot that asks for help with a
  sign-in and never gets it left a tool call nothing ever answered, and every later turn in that
  thread failed at the provider. This was fixed once for the framework Bot and not for the Bot in the
  box, which is the one behind the Browser Bot, so it went on happening where most people would meet
  it. Both now answer their own unanswered calls with the truth rather than a fake success.
- **A Bot refused because a person had the wheel was told its refs were stale.** The computer flags a
  takeover, the surface branches on that flag, and the flag did not survive the server, so a Bot was
  sent back round the same action against the person who had just taken the browser. Reported and
  fixed by @beardthelion.
- **A person could not take the wheel unless the Bot offered it.** The button appeared only after a
  Bot called for help, so the control a person needs depended on the Bot getting one instruction
  right, and when it did not there was nothing to press. It is there whenever the Bot is driving now.
  The Bot asking for help is still its own row, with its reason.
- **The first message of a new channel could be lost.** A new channel's thread does not exist until
  its first run, so the join that restores history had nothing to settle against; the message was sent
  anyway after a deadline, while that join was still in flight, and the join finishing replaced it
  with the thread's messages, which were none. The deadline now ends the join and waits for it, so
  nothing is left in flight to overwrite anything. The transcript also says it is loading rather than
  showing an empty conversation, and the thinking line is visible for the first time: a CSS rule
  blanked the colour a gradient was built from, so the glyphs were painted with nothing. Reported and
  fixed by @zopeVaibhav.
- **The in-memory snapshot store disagreed with the table.** The database only ever moves a snapshot
  forward; the in-memory one, which is what a test reaches for when it has no database, took whatever
  arrived last. A test could therefore prove a boundary property that is false in a deployment.
  Reported by @beardthelion, fixed by @NathanTarbert.
- **A computer that had opened nothing still reserved a browser-sized frame.** That put a placeholder
  the height of a browser window into the middle of a conversation, above an answer that never
  involved the browser.
- **A Bot named after a deployment route was served without its guard.** The computer router steps
  aside for `/policy` and `/fleet`, which are its own paths and not about a Bot, because Hono matches
  `/*` against zero segments and a single-segment path arrives as a Bot id. It stepped aside on the
  name alone, so it covered everything under those names too: `/policy/status` is `/:botId/status`
  with a Bot called `policy`, and for that whole subtree the access check was never called at all.
  The guard now steps aside only for the deployment path itself, and a Bot may no longer be named
  after one: a package declaring it is refused, and a deployment that already holds such a Bot
  refuses to start and names it rather than serving it. Reported and fixed by @beardthelion.
- **Upgrading never reached a Bot's computer.** A computer is a container the supervisor makes, and it
  was reused by name whatever image it was built from, so once a Bot had one, rebuilding the image
  moved the tag and the container went on running the old one indefinitely with nothing to say so.
  `docker compose down` does not touch these either, because compose did not make them, so even a
  full teardown left them behind. That is worse than stale code: the computer is the browser, the
  workspace and the confinement around both, so a fix to any of them silently did not apply. A
  computer built from a different image is now replaced on next use. Its profile and its workspace
  are volumes and are kept, so a Bot comes back on the new image still signed in to what it was
  signed in to, with its files where it left them.
- **The audit trail could be erased with one statement.** It is append-only because a database
  trigger refuses updates and deletes, and that trigger is row-level, so `TRUNCATE` never reached it:
  anything holding `DATABASE_URL` could empty the table and nothing raised. That is the case the
  guarantee exists for, since it is enforced in the database precisely because the application is not
  the only thing that reaches the table. A statement-level trigger now refuses a truncate, and it
  answers before the retention setting is read, so declaring a retention window no longer permits one
  either. Retention itself is unchanged: rows older than the window are still removed, and recent
  ones are still refused. The connection the application uses is the database owner in the shipped
  compose file, and an owner can still disable or drop a trigger; closing that needs a role with
  `INSERT` and `SELECT` only, which is a separate change. Reported by @beardthelion, who also named
  the failure mode of the obvious fix and saved it from shipping as one.
- **A declined take-the-wheel destroyed the conversation.** A Bot that asks for help with a sign-in
  and never gets it left an assistant message holding a tool call that nothing ever answered, and
  every later turn in that thread failed at the provider. Declining once meant nothing you typed
  afterwards got an answer, with no way back but a new chat. Unanswered calls are now answered when
  the history is rebuilt, with the truth rather than a fake success: no result came, the run has
  ended, carry on without it and say what could not be done.
- **The audit trail could not say why a conversation went where it did.** It recorded the router's
  choice and recorded nothing at all when a person named a coworker with `@`, which is
  indistinguishable from a row that failed to write. A mention is now recorded too, as the person's
  own choice, without asking the model a question they had already answered. The audit page names the
  coworker and separates the three cases: chosen by the person, matched by the router, or the default
  because nothing matched.
- **A Bot with half a connector sent people to a sign-in box.** Granted a vendor's search but not its
  read, it found the document, could not read it, and opened the vendor's website to try, where it
  met a sign-in wall and asked the person to take the wheel. They already had access; the missing
  thing was the Bot's grant, and nothing said so. A gap in what a Bot holds is now reported as a gap:
  it names the capability it would need and says an administrator can grant it on that connector.
- **Answers arrived with no sign of where they came from.** Asked a compliance question, a Bot
  replied with a filing obligation, a dollar threshold, a deadline and a retention period, and the
  audit trail for that turn held one row: the routing decision. A confident unsourced answer is
  indistinguishable from a confident wrong one. Every Bot is now told to cite what it read and to say
  plainly when an answer is from its own knowledge instead. It is told this by the deployment rather
  than per agent, so it cannot be missing from the next Bot somebody adds, and it is explicitly not
  an instruction to go hunting for a source.
- **A Bot browsed to a vendor it already had tools for.** Granted Google Drive, asked what was in a
  document, it opened `drive.google.com` in its own browser, met a sign-in page that browser can
  never satisfy, and asked the person to sign in to an account they had already connected. A tool
  array says a tool exists; it does not say the tool is the way to reach that system, and it was
  competing with a page of prose about the browser that mentions connectors nowhere. A Bot is now
  told which systems it holds tools for, generated from its grants and placed before that prose, so
  enabling a connector changes what the Bot is told on its next run.
- **A question went to a coworker that had no way to answer it.** Routing read the sentence somebody
  wrote about what a coworker is for, which is not the same as what it can reach, so a question about
  a Drive document went to the one whose description says "company knowledge" and which held no Drive
  grants. Candidates now carry the systems they hold tools for. Purpose still decides first: a
  specialist with no connectors is still right for a question about its specialism.
- **A deny rule about submitting a form was walked around by typing.** `computer_type` takes a
  `submit` flag that presses Enter once the text is in, and the policy never saw a key, so a rule
  refused at the button and at the keypress let the third route through. Both shipped copies of that
  rule name both tools now, the key reaches the policy, and the audit row carries it — without it a
  row said a field was filled in rather than that a form was sent.
- **A Bot refused at the door left no trace.** A callback that could not prove which Bot it was
  returned 401 and wrote nothing, so a Bot holding a token the deployment no longer accepted had
  every call refused, returned nothing to its own model, and the model told the person there were no
  results. A false negative delivered as an answer, with the audit trail agreeing nothing had
  happened. Recorded now as `mcp.callback_refused`, naming the tool and the reason but no Bot or
  actor, since both arrive in the credential that just failed to verify.
- **An unanswered request for the wheel followed a Bot around.** Control belongs to a Bot's computer
  rather than to a conversation, so a request nobody took sat there indefinitely and every later
  conversation with that Bot showed a live prompt for work it was not doing, captioned with a reason
  written for somebody else. An unanswered ask now stops being shown after ten minutes and its reason
  goes with it. A person actually holding the wheel is never timed out.
- **`/admin/computers` listed nothing, ever.** Admin addressed the fleet through a per-Bot route with
  a placeholder id, which stopped working when that route began checking whether the caller may act
  as the Bot in the path. The screen renders nothing while the list is null, so a deployment with two
  running computers looked like one with none. The fleet has a route of its own, still
  administrator-only.
- **Every shipped component was recorded twice on a first start.** Two browsers announcing at once is
  ordinary and the insert was already safe for it; the answer was not, so the loser of that race
  named every component anyway and the caller wrote an audit row per name.
- **A Bot could reach the deployment's own network by writing the address a different way.** The
  guard refused `169.254.169.254` and the private ranges as usually written, but not the same
  addresses spelled as an IPv6-mapped or NAT64 form, an integer, or with a trailing dot, so a Bot
  talked into fetching one still reached cloud metadata or an internal host. The address is
  canonicalised before it is checked now, the mapped form of `0.0.0.0` (which reaches every local
  port) is refused, and the container credential endpoints a hosted deployment must never expose —
  ECS and Fargate's `169.254.170.2`, Alibaba's `100.100.100.200` — are refused even when the
  private-host opt-in is on. The same guard backs agent registration, so it is closed there too.
- **The supervisor could adopt a container it did not create.** When starting a Bot's computer hit a
  name already taken, it started whatever held the name and handed it the deployment's computer
  token, so on a Docker host shared with anything else it could drive a stranger's container as a
  Bot's. It now refuses a container that does not carry its own namespace label, read from the
  container rather than inferred, so a second deployment on the same host is never adopted.
- **Removing somebody left the credentials they had granted this deployment sitting in the vault.**
  Removing them from the People screen ended their sessions and stopped the next sign-in, and left the
  refresh token behind, unrevoked. They could not use it — the account comes from a session they no
  longer get — but "we removed their access" was not true of the token, which for a connector read as
  the person asking is the part that matters. Removing somebody now retires it, and each retirement is
  on the audit trail as `mcp.account_disconnected`. Deleting a person's row used to be worse, because
  it took the connection record with it and left the credential reachable by nothing at all; those are
  found and retired too. This stops the deployment holding a usable secret. It does **not** withdraw
  the grant at the vendor, which needs revoking there until disconnect ships, and the audit row says
  which of the two happened rather than implying both.
- **The one-container image registered a coworker it could not run.** `MANAGED_AGENT_AG_UI_URL`
  defaulted to `localhost:4201` and was required, so Risk Analyst appeared on the roster and every
  conversation with it failed. The URL is optional; the package omits that coworker when it is
  unset. `scripts/start.sh` still points it at `agent-langgraph` on a laptop.
- **A boundary rule applied on one server out of N.** The policy is read from memory on every action,
  which is right, but memory was only ever filled at boot. An administrator's new deny rule was
  enforced by whichever process served the request and roughly one action in N went through it, while
  the admin screen reported success because the row really was saved and the audit trail agreed
  because it records the boundary each process started with. Both honest, and both describing
  something other than what the fleet was enforcing. A write now announces on Postgres in the same
  transaction and every server re-reads, including on reconnect, so a server that was down when the
  rule changed catches up rather than waiting for a restart. Reset travels the same way.
- **A ref resolved on one replica and nowhere else.** The gateway turns the opaque ref in a click into
  the element it points at, and that mapping lived in a `Map` in the process that took the snapshot.
  On any other replica the ref resolved to nothing, so a deny rule written about the element did not
  match and the click went through, recorded as allowed with no rule. It is in Postgres now, keyed on
  the generation the computer stamped, so a ref from a superseded page still resolves to nothing.
- **Anybody signed in could act as anybody's Bot.** The Bot id travels in the path and the acting
  routes checked only that somebody was signed in, so a signed-in person could drive another person's
  private Bot, reset its browser, read its screen and fire its granted tools. Every route under a Bot
  id now asks the store the same question the roster already asks, and a Bot that does not exist and
  one belonging to somebody else answer identically.
- **The computer fleet listing was open to any signed-in person.** It ignores its `:botId` and returns
  every Bot's machine, so it told anybody who could reach it every Bot id in the deployment and
  whether each was running, private coworkers included. Administrator-only now.
- **A Bot id could name a directory outside the profiles volume.** The id arrives as a URL segment or
  a header, was joined onto a filesystem path, and `reset` deletes that path recursively as root, so
  `../../tmp/something` deleted it. Refused at the request boundary and again where the path is built.
- **A mistyped deny rule permitted instead of refusing.** A rule that parsed and evaluated but
  answered with something other than true or false was neither a match nor an error, so
  `deny: ["Submit order"]` — what somebody writes who reads the list as labels — let the action
  through with nothing logged, while the rule sat on the Boundaries page looking as though it were in
  force. Any non-boolean answer is now a broken rule and takes the existing fail-closed path.
- **Rotating a Bot's key left the old one live.** Editing a key wrote a new vault row and repointed
  the Bot at it, leaving the previous credential decryptable and still valid with nothing listing it,
  so rotation did not do the one thing rotation is for. Deleting a Bot left its key live too. Both
  revoke now.
- **Nothing recorded what changed about a Bot.** Ten mutating routes wrote one audit row between them
  and there was no event type for any of the other nine. A Bot's endpoint is where conversation
  content is sent, so "who pointed this Bot at that host, and when" is the first question in an
  incident and could not be answered. Eight event types and eight rows now, recording what changed and
  never a value.
- **The people list and the channel list grew without bound.** Both were read in full on every render,
  and reading one person ran the whole people aggregate over the deployment twice per role change.
  Both are paged now, and the people screen searches on the server so somebody can be found without
  walking pages.
- **A computer accumulated one browser per Bot, forever.** `COMPUTER_MAX_BROWSERS` and
  `COMPUTER_BROWSER_IDLE_MS` set the two limits. Nothing closed an idle one, so a deployment
  where every employee has a Bot trends toward a resident Chromium per employee in one container until
  it is killed for memory. There is a cap and an idle timeout, and closing one costs only a relaunch
  because the profile is on disk.
- **The audit screen's filters were sequential scans.** It filters by event type, by who did it and by
  what it was done to, and the only index was on the timestamp, over what becomes the largest table in
  the deployment. Each filter leads its own index now.
- **A deployment with no identity provider came up open by default.** Covered under Changed above,
  and listed here too because it is the one on this list that was reachable from the internet.
- **Registering a company's identity provider was owned by whoever registered it.** Better Auth
  answers its own listing route with only the providers the person asking registered, and refuses a
  removal from anybody else, so a second administrator opened the Identity providers screen, found
  it empty, and registered one that already existed. Worse, the row cascaded from that person's user
  row: deleting the administrator who set sign-in up deleted the company's sign-in with them. What is
  registered is a fact about the deployment, so reads and removals go through OpenBot's own
  administrator-only routes against the whole table, and a provider outlives the person who added it.
- **A customer's client secret was in the clear.** The SSO plugin writes `oidc_config` and
  `saml_config` as plaintext JSON, with the OAuth client secret for that company's directory inside
  them: the one secret here not going through `KEY_ENCRYPTION_KEY`. Both are now encrypted at rest.
  Rows written before this still read, and are re-encrypted the next time they are written. OAuth
  access and refresh tokens use Better Auth's own encryption, keyed on `BETTER_AUTH_SECRET`.
- **A failed provider registration looked like a button that did not work.** The error was rendered
  on the page behind the dialog, which was covering it.
- **Deleting a component in the playground could release one the build ships.** `DELETE
  /api/sandboxed/:name` deleted from the shared components table by name, without checking
  which kind of component the name belonged to. Naming a compiled component removed its
  governance row, and the foreign keys took that component's per-Bot withholdings and its
  function grants with it. Withholding is the half that fails open: a published component is
  available to every Bot unless a row says otherwise, so the next catalogue announcement brought
  the component back published, and available to a Bot it had deliberately been kept from. The
  audit row called it `kind: "sandboxed"`. The endpoint now refuses a name this surface does not
  own and answers 404, the way publishing already did. A governance row whose source is already
  gone is still this surface's to clear.
- **A write could follow a symlink out of the Bot's workspace.** The confinement resolved the
  directory a write would land in but not the name it would land on, so a link left at `notes.txt`
  pointing outside was followed by the write; a read through the identical link was already refused.
  The gateway had already decided and written the audit row against the path as it was asked for, so a
  rule written for `credentials/` never saw the file that was written and the trail named a file
  nothing had touched. A dangling link escaped the same way, because resolving the path throws where
  the write would still land. Links pointing back inside the workspace continue to work.
- **A Bot could become root inside its container.** `sudo` was granted as `NOPASSWD: ALL`, and the
  comment above it named the two conditions that made that acceptable: the container being one Bot's
  alone, and not holding a database. The image meets neither, because the supervisor is deliberately
  not in it and `EMBEDDED_POSTGRES=on` is a documented way to run it. So root read another Bot's
  workspace, the API's environment, and the audit database recording what it did. The grant now names
  the package managers, so `apt-get install` still works and `sudo cat /proc/1/environ` does not. It
  is a floor rather than a boundary: code a model wrote needs a computer per Bot with
  `COMPUTER_SUPERVISOR_URL` and a sandbox under it with `COMPUTER_RUNTIME=runsc`, both of which this
  already supports and neither of which the single-container image can reach.
- **A command could take the computer down, or outlive being stopped.** Output was accumulated in
  full and only trimmed at the end, so `cat` of a large file allocated until the process that owns
  the browser died; it is now bounded as it arrives, and still reports that it was truncated rather
  than quietly ending. A stop signalled bash alone, so `sleep 30 | cat` left its children holding the
  pipes and the call never returned; the whole process group is signalled now. A `timeoutMs` of zero
  or less killed the command before it started and called it a timeout; it has a floor as well as a
  ceiling.
- **Stop did not reach a running command.** The `/exec` route never took the person's abort, so the
  plumbing for it was dead code and a stopped run left the command finishing inside the container.
- **The live-screen socket did not check the address it was given.** Every acting path resolved
  through the gateway, which refuses a foreign or cloud-metadata address; this one asked the provider
  directly and then put `COMPUTER_TOKEN` in the query string of whatever it was told.
- **`COMPUTER_SHELL_ENV` refuses the names that run before a command.** Naming `GITHUB_TOKEN` is an
  operator deciding a Bot may use a token. Naming `BASH_ENV`, `ENV`, `LD_PRELOAD` or the shell option
  variables is handing a Bot a hook into every later command, which is unlikely to be what was meant,
  so those are refused and said out loud rather than passed. A name that is not a variable name is
  now reported too, instead of quietly disappearing.
- **A deny rule naming one field refused every action that did not have it.** `deny:
  contains(command, "rm -rf")`, the example the documentation gives, refused every click, keypress,
  navigation and file read in the deployment. Two correct behaviours combined into a wrong one: the
  policy context left out fields an action did not have, cel-js treats a missing field as an unknown
  identifier and throws, and a thrown deny counts as a match so that a mistyped deny refuses rather
  than quietly permitting. Every field is now bound, with a neutral value where the action has
  nothing to put there, so a rule about a shell answers honestly about a click instead of refusing
  it. Rules about the action they are for are unchanged. The audit row still omits what did not
  happen.
- **A command longer than 45 seconds reported failure while it carried on running.** The transport
  gave every call the same deadline, which was shorter than the shell's own 120 second default and
  600 second maximum, so `apt-get install` told the person the computer had not responded and then
  finished installing inside the container. A command now gets a deadline that outlasts the shell,
  which reports a timeout itself and says so.

- **A Bot's shell no longer inherits the deployment's environment.** Commands ran with the computer
  process's own environment, so `env` in the one-container image printed `KEY_ENCRYPTION_KEY` and
  the rest of `.env`. The shell now receives PATH, locale and terminal names, and the proxy
  variables. Userinfo is stripped from a proxy URL, so a password in `HTTP_PROXY` is not in `env`.
  Anything else is named in `COMPUTER_SHELL_ENV`.
- **A deployment served over plain HTTP could not start a conversation.** The chat surface minted
  identifiers with `crypto.randomUUID`, which browsers withhold outside a secure context. On a
  laptop `http://localhost` counts as one, so this never showed up in development; on a real
  address it does not, and the surface did nothing at all when you pressed send. No message, no
  error. Ids now come from an API with no such restriction.
- **A Bot asked to be signed in, in words, and nothing happened.** Handing over the browser is a tool
  call, and a sentence in the transcript is not one: "please sign in and let me know" leaves the
  person with no wheel to take and the page where it was. Bots wrote that sentence anyway, and one
  went further and asked for a username and password to be typed into a sign-in page nobody could
  reach. The guidance now says that calling `computer_request_help` is what asking means, names the
  sentences that are not it, and says the person cannot see the page at all until control is handed
  over. Asked to file an issue on a site it was not signed in to, a Bot now offers the wheel on the
  first attempt instead of the third.
- **A package Bot did not know it had a computer.** The instructions that make the computer usable —
  snapshot before acting, and ask a person to take the wheel at a sign-in rather than reporting the
  task as impossible — were imported by the two shipped Bots and by nothing else, so a built-in agent
  knew only the role its package gave it. The tools were on offer to it the whole time. Asked to file
  an issue on a site it was not signed in to, it browsed to the page, said it could not, and never
  called `computer_request_help`, so nobody was ever offered the wheel. Built-in agents are now told
  the same thing the shipped Bots are told, wherever a computer is configured.
- **A chat could quietly forget everything and carry on.** The browser remembers a thread id for each
  Bot, and nothing ever asked whether Intelligence still had that thread. Where it did not, the
  transcript loaded empty, every later message silently recreated an empty thread under the same id,
  and the Bot answered as though the conversation were new — with the reason nowhere but the server
  log, as a 404 flattened into a 500 by the time it reached the browser. A remembered thread is now
  checked before it is used: one the platform provably does not have is replaced, because there is no
  conversation left to lose, and a check that fails for any other reason keeps the thread and says on
  screen that earlier messages could not be loaded. A person reading a confident answer can now tell
  whether the Bot has read what came before it.
- **The first browser action a Bot was ever asked for failed.** Creating a computer and starting it
  are two calls to Docker, and a name the daemon has not published yet answers the second with a 404.
  The supervisor treats that as a lost race and rebuilds, which is right, but it went straight back
  round: the retry landed a millisecond later, saw the same unpublished name, and spent the only
  other attempt on it. The whole request then failed as Docker being unreachable, the person was told
  the computer could not be started, and the next message worked. It waits one poll interval before
  rebuilding now, which is what the health wait already uses for the same question.
- **A framework Bot asked for a browser action and nothing happened.** `agent-langgraph` ends a run
  when the model calls a tool the surface owns, which is how a tool that lives in the browser is
  supposed to work: the run finishes, the surface acts, and the next run carries the result. But the
  call was only reported to the surface from the node that executes this deployment's own tools, and
  that node is exactly what an ending run skips. The person saw their own message, no answer under
  it, and no explanation, because a run that finishes carrying nothing is not an error. Every Bot
  action in the browser was affected: opening a page, filling a form, asking for help at a sign-in.

### Changed

- **A retention policy for the audit trail.** `AUDIT_RETENTION_DAYS` removes rows older than the
  window it names, swept hourly by whichever server holds an advisory lock. Unset by default, because
  deleting somebody's audit trail because a default said so is the worse of the two failures. The
  trail stays append-only: the database permits a delete only when the transaction declares a
  retention window and only for rows already outside it, so removing recent rows is still impossible
  and an `UPDATE` still is under every condition.
- **`allowed_groups` is documented as a declaration, not a control.** The tenant package writes it and
  nothing reads it on any access path, and `users.groups` is written by nothing either, so both halves
  of the rule are waiting on group membership arriving from the identity provider. Channel access is
  membership alone. The columns stay, because they are the right shape for the rule they are named
  for. Thanks to [@NathanTarbert](https://github.com/CopilotKit/OpenBot/pull/92) and
  [@andreolf](https://github.com/CopilotKit/OpenBot/issues/82).
- **Running with no sign-in takes a flag and nothing else.** It used to be locked with
  `NODE_ENV=production`, which is exactly backwards: `NODE_ENV` is unset unless somebody sets it, so
  a container on a VM with a hand-written env file and no identity provider served every visitor on
  the internet as an administrator, silently, because nothing looked wrong from the outside. A
  deployment with no provider now refuses to start unless `OPENBOT_SINGLE_USER=true` says it was
  meant. `.env.example` ships that line switched on, so a clone still runs with no configuration at
  all, and the line is greppable in a way a default never was. `OPENBOT_DEV_NO_AUTH` is still
  honoured.
- **Requires Better Auth 1.7**, which adds an `issuer` to every account. Migrations `0002` and `0003`
  add the column and backfill existing rows with their provider's real issuer, so nobody is asked to
  sign in again. The column stays nullable on purpose: a rolling deploy runs migrations and then
  serves from old and new replicas at once, and an old replica writes an account without it, so
  making it required in the same release would break the first sign-in of everybody who landed on a
  replica that had not been replaced yet. The constraint belongs to a later release.
- **Where a Bot's computer runs is now a plug.** One `ComputerProvider` interface sits under the
  gateway, with the Docker supervisor as one implementation and a shared computer as another. A
  computer somewhere else is an adapter rather than a change to the governed path. Thanks to
  [@mu-hashmi](https://github.com/CopilotKit/OpenBot/pull/57) for the refactor.
- The address a provider hands back is checked before anything is sent to it, and the cloud metadata
  addresses are refused whatever a provider says.
- The container image runs as an unprivileged user rather than root.

## 0.0.1

First tag.