[prysthedev]

Any signed-in person could register a Bot at an address of their own and mark it public. A public Bot is offered to every person in the deployment, and a remote one is sent each of their conversations along with the run assertion it calls tools with, so the person running that server saw what everybody said to it and could act as each of them within the Bot's grants.

Creating a public Bot with its own endpoint, or making a remote Bot public, is now refused for anyone but an admin, with a message that points at keeping it private and sharing it with named people. Bots with no endpoint, or on the deployment's own managed Bot, are unaffected, and admins can still publish remote Bots.

What this changes

Where it runs

OpenBot is deployed as several server processes behind a load balancer, serving a whole company.
Consecutive requests from the same person reach different processes, and the process that answered a
WebSocket upgrade is rarely the one that answers the next call on that conversation.

State that outlives a single request therefore has to be shared, or the change works on one machine
and stops working the moment there are two, without saying so. That failure is worse than not
shipping the feature: it passes review, passes CI, passes a local demo, and only surfaces as a Bot
that forgets, a question nobody can answer, or a boundary that never fires.

Answer these even when the answer is "none":

• New state that outlives a request? Where does it live? A Map or Set held in a module or
  a factory closure does not count as somewhere.
• What happens on the second replica? Name the concrete outcome, not "should be fine".
• Anything serialised? Say what stops two processes doing it at once. A unique index, a
  conditional update, or an advisory lock are answers. A check-then-write is not.
• Anything fanned out to a browser? Say how it reaches a socket held by another process.
• New listener, port, or schedule? Say how it is reached through the same ingress as the API,
  and what a hundred copies of it do.

Postgres is already there and is the default answer to all of the above: a table, a unique index, a
conditional update, LISTEN/NOTIFY for fan-out.

Boundary and audit

• Every acting call still goes through the gateway: resolve, decide, audit, then act.
• New refusals and new failures each write a row.
• Nothing new is trusted from the client that the server can resolve itself.

Changelog

• A line in CHANGELOG.md under Unreleased, or a sentence on why a deployment behaves no
  differently afterwards.

Proof

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	⚠️ Failed 2026-10-29T23:42:02.884201Z We couldn’t complete this review. Comment @codex review to try again.	85d3639	PR opened

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.