The longest runbook a skill may save and how much of it load_skill hands
back are now set on Settings > General (skill_body_max_chars,
skill_body_shown_chars), defaulting to AppData.SkillBodyMaxChars and
SkillBodyShownChars. Saving, confirming and proposing a skill check the
install's limit; a skill saved before it was lowered can still be toggled.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
A bot's powers came from bots.kind alone, so only the coordinator could
hand work to other bots. bot_types now works like user_types: a row with
no workspace holds everywhere (the coordinator), one with a workspace
only there (a workspace admin), and no row is a worker. bots.kind stays
the legacy marker of the one coordinator for who sees it.
The matrices in src/dict/bot-types-dict.ts say what each type may do,
whom it may direct and who grants it, read by one generic interpreter
(rbac/type-assignment.ts) that userTypeAssignment now wraps too. Every
run reads its powers once (grabBotRunPowers) and the chat tools, task
runs and task tools gate on them instead of kind; a run's powers are its
type's and its user's together.
In the workspace it leads, an admin hands tasks to the workers there
(results relayed back to it), sets their instructions, adds tasks to
their lists and keeps the workspace's context when its user may. Super
admins and admins grant it from the workspace's settings or the chat
header's menu, and the coordinator with set_bot_type. Admins are marked
with a filled green shield beside their name across the workspace, kept
live by pushBotUpdated's admin_workspace_ids.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
A data archive or restore ran inside its request, which sent nothing
until tar finished: Bun closes a silent socket after 10s (its default
idleTimeout in production) and a proxy cuts it at about 100s, so the
page showed a network error while the archive kept going, and a retry
said another backup was already running.
The routes now start the run (startDataBackupRun, refused while the
backup lock is held) and answer at once. The page follows it by polling
api/admin/backups/data-status: an archive reloads once written, a
restore once the status comes from a new process after its restart,
and a failure shows its error. A run in progress survives a reload.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
Computers now mount only /home/gem/workspace from DATA_DIR/computers/<id>,
so only the workspace persists and goes into the data archive. An older
computer's whole home is moved aside to <id>-home-<ts> (kept, never
archived) and its container recreated once by sync-computers.
Each run works in bots/<bot>/users/<user> (also its cwd and HOME), with
bots/<bot> for work every user shares and workspaces/<id> shared by a
workspace's bots; the coordinator reaches the whole workspace. Computer
tools are gated by withComputerDirs: bash and code start there, file tool
paths and file: URLs outside the run's folders are refused, and so is sudo.
search_computers, import_file and script tools start there too.
The files browser shows members only the bots' folders they reach, their
own user folder in each and their workspaces', with names on the id folders.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
- Coordinator tools in its own chat (super admin only): list_extensions,
set_extension_access, delete_extension, and update_skill /
update_mcp_server / update_custom_tool for what can't change where
anything is sent (on/off, names, arguments, left-out tools)
- Adding a skill, MCP server or tool, or changing a skill's words, a
server's URL or headers or a tool's kind or config, goes through
propose_skill / propose_mcp_server / propose_custom_tool: stored in
extension_proposals with the bot's background check, shown as a
[proposal:ID] chip that opens a card with Confirm and Reject
- The card's facts are worked out by the app from what Confirm saves: the
host, every {{env.KEY}} and whether it's saved, the config; for a skill
its links, hosts, tool names, mentions of secrets and a diff against
the saved runbook
- Confirming decides once and checks again; a server or tool missing a key
is saved switched off, and the outcome is posted to the bot in chat
- Never from a bot: stdio servers, a URL whose host a template decides,
envs in a prompt tool, a key's value
Co-Authored-By: Claude Opus 5.5 <[email protected]>
Every bot message gets an info button that opens its details: the
provider and model behind it, tokens and cost, the job that ran it, each
model used and every call in order. Each model call now records how it
was made in token_usages.settings (generation settings sent, whose
settings they were, pinned or automatic model, fallbacks), shown per
model in the modal.
Live replies now carry their token usage, from the job's push and the
live relay alike, so it shows without a reload.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
The conversation pages rendered their messages on the server, so a page
the back button restored from the back-forward cache showed an old
thread. The server now renders everything else (rail, header, composer)
and the history (active session, latest messages, active task) loads
from api/admin/bots/conversation-history once the page is on screen,
with a loading line under the header, and again on a pageshow restore.
Messages sent or pushed while it loads are merged with it.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
The two limits were compiled in: a task run stopped at
AppData.HarnessMaxToolSteps (200) and a chat reply at
AppData.BotReplyMaxToolSteps (8), so an install that needed a longer task
had to rebuild.
Both are now `app_settings` rows (`harness_max_tool_steps` and
`bot_reply_max_tool_steps`), read at the two loop call sites through
grabHarnessMaxToolSteps and grabReplyMaxToolSteps, and edited by the super
admin on Settings > General beside the prompt appendix. Zero clears a
limit back to the code default, like the bot file quota.
readStepLimit keeps the saved number only when it is a whole number of at
least 1 and no more than AppData.BotStepLimitMax (1000), so a blank, a
zero or a typo falls back instead of stopping every run before its first
turn, and a huge number still ends in the wrap-up report.
runTextLoop keeps AppData.HarnessMaxToolSteps as its default, so it stays
free of database reads and its tests run as they did.
Nothing anywhere recorded what a model call cost: the harness used a
provider's usage numbers only to decide whether a turn had finished, then
dropped them. So a reply could not say what it took to make, one model
could not be compared with another on price, and there was no way to ask
what a day, a week or a month of the crew's work came to.
- `token_usages` records one row per call: user, bot, workspace, session,
job and message, the harness, the provider and model that actually
answered, the prompt and completion counts, and the cost when the
provider reports one.
- `harness-usage-scope.ts` carries those ids in an AsyncLocalStorage
scope that `run-bot-job.ts` enters once, so a run's turns, its session
summary, its transcriptions, images and embeddings are all attributed
without threading ids through every harness function. Nested runs merge
rather than replace, and a null genuinely clears a field (a bot's own
chat has no workspace).
- Work with no run behind it is charged to its owner instead:
`run-with-fallback-scope.ts` reaches the workspace's creator else the
bot's, and deliberately does not override a real run, so an ingest a
bot asked for is not misattributed to the bot's owner.
- All six harnesses record through `withCandidates`'s `on_success`.
Recording never throws: a model that answered must not lose its answer
to a failed insert.
- A job's calls land before its message exists, so `complete-bot-job.ts`
back-fills `message_id` once the message is inserted.
- The message's actions row shows what it cost, beside the timestamp and
the play button, with the breakdown in its title.
- `/admin/usage` totals the install's spending for 7, 30 or 90 days: the
total against the previous period, a day-by-day chart, a split per kind
of call, and a table per model with the price per thousand tokens
worked out from cost and tokens, which is what makes two models
comparable. Crew managers only, since it is the whole install's work
rather than one user's conversation. It sits with Routines and Activity
in the user popover rather than under Settings, because it is a record
of what happened, not something to configure.
Days are grouped in local time (`date(created_at / 1000, 'unixepoch',
'localtime')`), matching the local midnights the window builds and the
`YYYY-MM-DD` buckets it looks up. Grouping by the bare UTC day put a late
evening's calls under a name no bucket carried, so they vanished and the
chart's total silently disagreed with the totals card; a test pins it.
`canSeeRailItem` now decides who sees a popover or rail entry. The two
each filtered with their own inline rule and only one understood
`can_view`, so a gated page could be offered in the popover to everyone.
The thinking row and the header menu both carry Stop while a bot has work
open for the user anywhere: every pending or processing job of that bot in
their conversations is failed as stopped, its task closed, a Stopped step
recorded and one closing message posted per session, so the thread stops
waiting and the bot goes idle. The handler running the job is aborted from
this process through a registry, so a job stuck waiting on a model stops at
once instead of on its next heartbeat, and a late face change after the
abort is dropped.
The release stage is now said in the app too: Settings > General reports
"Cobble v0.1.5 (alpha)" next to development, and the README and RELEASING.md
say what alpha means for installs.
A new super admin settings page, /admin/settings/database, lists every
table with its record count and size, and one page of the open table's
records newest key first. Values are cut inside SQL (400 characters, with
a flag saying so) and a record opens whole in a modal, so a table of long
texts reads without shipping it all. A search matches every column's
text, word by word or as a phrase, which is the one thing that also works
on a virtual table. Nothing in it writes: the catalog, the records and
the single record are all reads, GET only.
A coordinator asked to set an uploaded logo as a workspace picture could
not: the picture tools take a media id, and nothing ever gave the bot one.
Attachments reached the model as "[Attached image \"logo.png\"]", every
file tool answers with a [file:ID] ref, and an SVG is deliberately stored
as a document rather than an image.
- copyMediaAsPicture copies an approved image into a new picture row
(bot-image/workspace-image). The source keeps its row and bytes, so a
message that attached it still loads and changing a picture can never
take a file away from a conversation.
- grabPictureSource resolves a picture by [file:ID] (the same scope gate
every file tool uses) or by the user's own upload; parseFileRef reads
the [file:12] form.
- The new set_picture tool ships on every run: a bot sets its own face,
the coordinator can also dress a worker. update_workspace gained
picture_file_id, and setBotPicture/setProfileImage share the copy and
the delete.
- removeReplacedPicture deletes a replaced picture only when it really is
one, never a chat upload.
- uploadAndRecordMedia writes images in their own format: PNG stays PNG
with its transparency, WebP stays WebP, GIF becomes PNG, everything
else JPEG, and the row records the real mime type (it used to say jpeg
for every image).
- Pictures change live: BotUpdatedData carries image_media_id and a new
server:workspace-updated pushes workspace pictures, relayed between
processes.
- Attachments are labelled with their media id, and BotFilesNote tells a
bot that a [file:ID] can become a picture.
- grabRunScopes is now the single source of a run's reachable folders,
shared by the file tools, imports and the picture tools.
The General page ends with a Version block naming the release this
server runs, so an update can be confirmed from the app.
The version is COBBLE_VERSION, the release tag the image was built with
(Dockerfile ARG, passed by the release workflow, which falls back to
package.json's version on a workflow-dispatch build), else package.json's
version, which a development server reports too, with (development)
after it. runningVersion (src/utils/running-version.ts) drops an
unusable version string rather than showing it.
Also includes the working tree's pending signup guard in
src/pages/__root.server.ts: a user who still holds a session while the
install has no users is sent to /auth/logout (and may load it).
A skill is a runbook: a name, a unique slug, a one-line description of when
it applies, and the markdown body. A run only ever sees the slug and
description (one load_skill tool carries them), and reads the whole body
only when it calls the tool, so a long runbook costs nothing until needed.
Skills are the third extension kind beside MCP servers and custom tools, on
the same botExtensionsSql path, so per-bot, per-workspace and all-bots
grants work the same way, and attachDefaultExtensions hands an every-bot
skill to new bots. load_skill is a reserved tool name, so a custom tool
cannot shadow it, and a built-in wins a clash.
Managed on Settings > Skills; ExtensionRow links each kind to its own page
and a skill never reports a failure, since nothing connects or runs.
A bot's identity was one of seven hues, and the hue picked both its colour
and its stone shape. Now its colour is free and its stone is its own:
- `bots.color` holds any `#rrggbb`, `bots.stone` the flat-cut shape it's
drawn on. `bots.hue` stays as the palette column they replaced, read only
as a fallback; `src/scripts/move-bot-colour-to-owners.ts` backfills an
install from it (safe to rerun).
- `src/utils/bot-color.ts` is the only place a colour is validated or
resolved (`resolveBotColor`/`resolveBotStone` carry the old hue forward,
`botColorNeedsPaperFace` flips the eyes to paper on a very dark body), and
`src/utils/bot-stone-props.ts` gives every row its props, so a row saved
before this still renders as it did.
- `BotStone` takes the colour as the body's SVG `fill`, the one documented
exception to the token rule: an arbitrary hex has no token to point at.
`UnreadDot` follows it.
- The picker keeps the palette tiles (still shape and colour together) and
adds a native swatch and a hex field, so a custom colour keeps its stone.
Same place as before: the header avatar's modal and Settings > Bots, for
crew managers. The coordinator stays hue-less.
- A recolour reaches other open tabs through `pushBotUpdated`.
Settings > General gains a prompt appendix the super admin sets once:
markdown every bot runs with, right after its own core instructions.
- The text lives in app_settings (bot_system_prompt_append, read through
grabSystemPromptAppend, cached like every app setting), so it changes
without a deploy and applies to every bot on the next run.
- composeBotPrompt takes an appendix and pushes it as
# Install-wide instructions directly after system_prompt, before the
workspace block and memory, so the bot's own more specific rules still
win. grabBotPrompt feeds it in, so chat replies, tasks, scheduled runs
and the coordinator all get it with no call site touched.
- api/admin/settings/system-prompt-append saves it (super admin only,
capped at AppData.PromptMaxLength, empty clears it) and is audit
logged under system.
- The section and its form are hidden from everyone but the super admin,
save in place with a character count and no reload, and say what an
empty text does.
Settings > Backups gains a whole-data archive beside the database
snapshots, and both lists now fully work from the page.
- Data archives: `write-data-backup-archive.ts` tars all of DATA_DIR into
BACKUP_ARCHIVE_DIR as cobble-data-<epoch-ms>.tar.gz, every entry under one
root folder named after the archive, writing a .part name and renaming on
success so a cut-off run is never listed. The newest
AppData.DataBackupsKept are kept; db/.backups is left as it is.
- Restore: `restore-data-backup.ts` extracts to a temp dir, requires one
root folder holding a db folder, takes a safety archive first, then
replaces DATA_DIR (the database snapshots included) and `restart-app.ts`
restarts the process through the docker socket, since the open SQLite
handle points at the replaced file.
- Upload and restore: a modal over each list (database file or data
archive), replacing the old /admin/settings/backups/restore page.
- Delete for both kinds, icon-only row actions shared through
RowIconButton, and restore on every row.
- One backup or restore of either kind at a time (with-backup-run-lock).
- BACKUP_ARCHIVE_DIR is a start-up path (ProcessOnlyEnvKeys); the installer
mounts $COBBLE_HOME/backups-archives at /backups-archives and recreates a
container that lacks it. The image installs tar and gzip.
A bot's folder chip went to bare /admin/files instead of the folder it
named, and even once there the computer volume pointed at the wrong
directory, so the folder a bot linked to looked empty.
The chip lost its folder because folderRefUrl only accepted a ref's
volume name (computer) while the chip hands it the browser's
(computers), so storageVolumeFromRef found nothing and the whole query
was dropped. Both spellings resolve now, through parseStorageSpec, so a
bad owner falls back cleanly instead of emitting owner=0.
The deeper bug: a computer's home was assumed to be
DATA_DIR/computers/<id>, but on a bind mount it can be anywhere on the
docker host, and a computer the app didn't provision (the main one on a
server reached at MAIN_COMPUTER_URL, i.e. a dev server outside docker)
records nothing at all. resolveComputerHomeDir holds the precedence:
the directory provisionComputer actually bound in
(containers.metadata.data_dir), else the new MAIN_COMPUTER_DATA_DIR app
setting for the main computer, else the conventional folder.
A path that isn't on disk also no longer reads as an empty folder:
listStorageEntries reports it as missing and the page says so, so a
stale folder link can't look like a folder nothing has written yet.
There is no public media any more. `/media/public/<id>` served a media
row with no session at all, so anyone with the id could read a file.
The public/private split is gone: the path is `/media/<id>` (and
`/media/<id>/thumbnail`), every request is signed in first, and
`grabUserMedia` decides whether the user may see it: their own upload,
a bot's or workspace's picture or file they reach, or a file on a task
they reach. Anything else is a 404 before a path is built.
The `media.is_private` column and the two per-user directories went
with it: uploads live in `media/<user_id>/` and there is nothing to
pick between. The files browser's media volume is now the viewer's
own folder whatever their role.
Bots also say which of the two things they mean. A `[file:ID]` ref is a
saved file and its chip opens the bytes; a folder is a new
`[folder:volume:owner:path]` ref (`src/utils/folder-ref.ts`) whose chip
opens the files browser there and downloads nothing. The old `[path:...]`
ref and the extension sniffing that guessed file from folder are gone,
so `import_file` names the folder holding a file it copied rather than
the file itself.
The prompts say what the Assistant got wrong: list before importing or
saving, one copy per artifact, never split a file into parts unless
asked, never claim the store is empty without a fresh list, and never
invent a size cap. A re-import now says the path already existed
instead of silently overwriting and reporting a fresh copy.
Envs had three scopes, general, workspace and computer. A bot had no
scope of its own, so the only way to give one worker a key was to set it
on a computer it happened to share.
The envs table gets a bot_id, and resolution now layers bot over
computer over workspace over general, so a bot's own key wins wherever it
runs. Every computer call site passes the run's bot_id, and grabRunEnvs
does the same for the {{env.KEY}} a custom tool or an MCP server's headers
read.
A bot's and a workspace's settings page can now edit their own envs, in
place, through the same save-env and delete-env routes: sending `scoped`
makes them answer with just that scope instead of the whole install's
overview. Super admins only, like the Environment page.
A bot's deliverables and the raw material behind them only existed as
paths in a message, so they couldn't be opened from the app at all. This
browses them read-only at /admin/files, one volume at a time: a bot's own
folder, a workspace's shared one, a computer's home (where a bot's ~/...
actually is), the media library, an MCP server's install folder and the
database.
Access is the whole gate: resolveStorageSpec checks the viewer against
the volume first (a bot through grabUserBot, a workspace through
grabUserWorkspace, a computer through grabUserComputer, media only their
own unless they manage the crew) and no path is built before it passes.
resolveStoragePath then applies the resolveBotPath rules to any root.
The picker lists folders through reachableBotsSql, so it never offers one
the resolver would refuse.
Reading is listStorageEntries (folders first, paginated, symlinks
skipped, catalog rows joined so a bot file still opens through its media
row) and grabStorageFile for bytes under a cap, both behind an ETag.
Bots and workspaces each keep a list of work tracked until it's done, and
the bots move it along themselves as they work.
- tasks (one collection per bot or per workspace), task_notes (the
progress log) and task_media (a deliverable or a reference file, its
bytes a private media row served at /media/private/<id>)
- statuses todo/doing/blocked/done/cancelled, with blocked_reason while
only the user can unblock it
- visibility as SQL in src/utils/task-access: a user's own bots and
workspaces, a run's own list plus its workspaces, everything for the
coordinator; every tool and endpoint resolves through it
- list_tasks, create_task and update_task on every run, so a chat reply,
a task and a routine all read the list, log progress and file what they
produced
- TasksNote on every run and TaskReminderNote in chat, so a greeting or a
proposed next step brings pending work up in one measured line
- tasks group on the workspace dashboard and a tasks modal in the
conversation header, sharing one form, row and detail panel
- a bot's or workspace's own chat uploads are read before the delete so
none are stranded; bot files keep their folder
Also corrects the README's RAM guidance and table alignment.
Each text and vision harness setting now carries the generation settings
its model takes (temperature, sampling limits, penalties, seed, reasoning
effort), edited in a modal under the model pick so the harness block stays
short. Nothing is set by default, so models keep their provider's own
values until a super admin or admin changes them.
A setting is only offered and only sent when the catalog says the model
takes it: OpenRouter's supported_parameters is now stored on
harness_models and refreshed by the hourly sync. Other providers list no
parameters, so their models get them all.
Bot and workspace lists in page props leave out instructions, memory and
workspace context, and carry the last message as a short preview. The
header avatar's edit form loads the bot's instructions when it opens.
The conversation renders its latest 30 messages and loads older ones as
the thread scrolls to its top.
Also: the composer shows a placeholder until its editor loads, and
`bun start` no longer builds first.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
In production, a page request without the running build's cookie gets a
small loading page instead of the app. It downloads every file in
.bunext/public (listed at /build-info.json) into that build's cache,
checks they are all there, hands over to a new service worker waiting
behind an older one, sets the cookie and reloads. The service worker
then serves the app's code from the cache, so later visits load it from
the device.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
- Cache the model catalog once per user and each conversation's setting
separately; clear both on logout and after model saves
- Compress hashed assets asynchronously with a byte budget and set Vary
- Memoize message parsing and throttle selection reads
- Debounce draft writes to localStorage
- Keep the composer editor on the page and focused, as before
- Add a bundle budget check and run it in CI
- Show a loading block while sessions load and a workspace avatar in the
mobile conversation header
- Compress responses: page scripts and styles once (brotli or gzip, in
memory) and cached immutable; pages and API JSON gzipped as they stream
- Service worker serves content-named assets cache-first
- Load the models modal's data when it opens (cached in localStorage)
instead of shipping the model catalog in every conversation page
- Lazy-load the Tiptap composer and memoize thread messages
- Import lucide icons directly; twui 0.1.4 drops by-name icons from Button
- bun run start builds the pages minified before serving
Co-Authored-By: Claude Opus 5.5 <[email protected]>
Every message has a row under it to reply or react. Replying quotes the
message above the composer, and the sent message stores
reply_to_message_id (a plain id, not a foreign key, so deleting the
quoted message only drops the quote). send-message accepts a quote from
any session of the same conversation, so a rollover or a thread that
moved on still sends; the conversation drops a picked quote when its
session changes. The bot reads the quote as "[Replying to ...]" before
the user's turn, file-only replies included, and relayed messages carry
it too.
Reactions are a fixed set (BotMessageReactions) in
bot_message_reactions, one per message, emoji and user or bot. Users
toggle their own through api/admin/bots/react-message, and every bot
gets react_to_message for the session it answers (the user's latest
message by default). Both push the fresh list as server:bot-reaction,
with mine worked out for the session's user.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
- A mic in the composer records, transcribes with the bot's
transcription model (api/admin/bots/transcribe) and writes the text
into the input at the cursor to edit before sending. Escape cancels;
recordings aren't stored.
- Every bot message has a read-aloud button that plays
GET api/admin/bots/speak-message, streamed from the provider as the
audio is made, so it starts in a couple of seconds. One message plays
at a time; only the user's own sessions can be read.
- Both buttons stay visible but disabled while the bot has no model for
them (bot_voice page prop).
- Transcription and speech no longer pick free models automatically:
they're not available until a model is picked, and Settings says so.
Transcription lists speech-to-text models only, so the chat-model
transcript path and its missing-audio check are gone.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
- Resolve the crew and workspaces fresh inside each tool run, so a bot or
workspace created earlier in the same reply is usable: create_bot,
assign_computer, add_bot_to_workspace, delegate_task and
set_bot_workspace_instructions.
- Add coordinator-only update_bot, find_bot, find_workspace, delete_bot,
delete_workspace and remove_bot_from_workspace tools.
- Push server:workspace-removed when a workspace is deleted, and
workspace_ids on server:bot-updated so a workspace's crew drops a bot
that was taken out of it.
Sessions no longer take their title from the first message: once the first exchange is sent, the text model writes the title and summary, which the rail and sessions list show. The summary records how many messages it covers so a stale one is rewritten before it is carried into the next session.
The sessions hook now reloads on live message and session events, so a session started by the first message, a rollover or another tab appears without a reload. New sessions are pushed as server:bot-session, both from the process that changed them and through the live relay.
Add a generated manifest, icon set, offline page and service worker that never caches authenticated HTML, plus install and update UI. Turn the rail into a drawer below md with container-query internals, dvh and safe-area handling, and reconnect the socket after visibility/network changes. Add Web Push subscriptions, presence-aware delivery, notification settings and tests.
Take the Bots and Workspaces pickers out of the user form. A user's
settings page lists what they reach in two groups, like a workspace's
Bots group: each row links to its settings and can be taken away, and
a select adds one, saved straight away through users/add-access and
users/remove-access (setUserGrant).
Co-Authored-By: Claude Opus 5.5 <[email protected]>
- Bots and workspaces get tools and MCP servers from their settings
pages; bots also from chips under the chat composer, removable there
- "Every bot" now gives one to every bot now and every new bot; each can
still drop it (attach-every-bot-extensions.ts moves old installs over)
- Status lines: MCP servers record whether they connect, tools whether
their last run worked
- Test connection in the MCP form and a Test panel in the tool form check
the form as it is, without saving
- Hide Google sign-in on the login form
Co-Authored-By: Claude Opus 5.5 <[email protected]>
Two new settings pages, MCPs and Tools. Super admins define them; super
admins and admins attach them to bots, to workspaces (every bot there),
or to every bot. Bots get them in chat replies and tasks.
- Custom tools: a JSON-schema of arguments plus an HTTP request, a script
on the bot's computer, or a prompt, templated with {{args.x}} and
{{env.KEY}}, secrets redacted from results.
- MCP servers: remote (URL and headers) or stdio commands run on the host
with a setup command and an isolated env, in a per-process pool. Tools
are listed into a cache and connect on first call.
- Add, edit, access and try open in modals.
- Markdown, JSON and command fields use twui's AceEditor (CodeEditor),
its scripts loaded on demand.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
create_workspace gives the coordinator a way to start a workspace with its shared context, and the tool list is shared, so a new id can be used by create_bot or add_bot_to_workspace in the same reply.
A coordinator's tasks now get create_workspace and update_workspace too: the research task that had the material could only report it, never write it into the workspace, so the coordinator promised an update it had no turn to make.
A workspace created from chat is pushed as server:workspace-created, from the tool and from the live relay, so the rail shows it without a reload.
A bot's face and status line live in bot_user_faces, one row per bot and
user, set by jobs for the user whose conversation they're in. Needs-you
and working only show to that user; every bot read overlays the viewer's
face (botFaceSql) and pushes go to the user a face change is for.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
The workspace rail now lists only the bots attached to the workspace, with the back link returning to the workspace page from a bot's conversation. /admin/workspaces/<id> becomes a read-only dashboard (picture, context, latest activity, bots, computers) that links into the editable settings page.
Deleting a bot only changed the page after a reload. The delete route now
reads who could see the bot before removing it, since its assignments and
workspace places go with it, then pushes server:bot-removed
(BotRemovedData) to them. useLiveBots drops the row, so every tab and
every workspace the bot was in updates together.
The rail was built from page props and only knew bots it already had, so a
bot the coordinator created did not appear until a reload.
create_bot and add_bot_to_workspace now push server:bot-created
(BotCreatedData) to everyone who sees the bot: its rail row, the
workspaces it is in, and whether it belongs in that user's own chat list.
useLiveBots inserts it, after the pinned coordinator outside a workspace
and only when the open workspace is one it joined. liveRelay pushes created
bots too, so a bot added by another process still shows.
Bots, workspaces and computers now belong to the install. Users reach
workers only through bot_users (assigned by a super admin or admin) and
workspace_users; the coordinator and main computer are one per install,
and only the super admin sees the coordinator. Conversations are per
user (bot_sessions.user_id), jobs run for the session's user, and live
updates go only to who should see them.
A bot's core memory is now general knowledge shared by every user it
works for; what it learns about a user lives in bot_user_memories.
One-off scripts move existing installs over: move-bot-memory-to-owners
(run first), then share-crew.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
- Settings > Users uses the people UserForm (useFormInit) instead of its
own copy; it saves in one request through users/save-user, which now
takes an optional profile photo (setUserProfileImage)
- Revoke action on user rows adds the revoked type, as the edit form would
- Every admin form asks for confirmation before it saves
Co-Authored-By: Claude Opus 5.5 <[email protected]>
Bots create, list, update and delete schedules (cron_jobs, Bun.cron in UTC);
a per-minute cron queues due runs as tasks. Routines, Activity (super admins)
and Help get their own rail aside. Help covers familiar problems, starting
with signing in to Google through Cookie-Editor over the new Desktop (noVNC)
view.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
- Rail: Add icon with stacked form modals (bot, workspace, computer),
coordinator, recent bots with "See all bots", Workspaces section, and
a workspace mode listing only its crew
- Workspaces: page for context, bots (per-workspace instructions and
memory), computers (default, link, unlink), models and delete;
conversations scoped per bot per workspace
- Sessions: conversations split into searchable, reopenable sessions
with carry-over summaries; sessions and new-session header icons
- Computers: created and provisioned over the docker socket, home dir
kept at DATA_DIR/computers/<id> after delete; super admins only
- Models: workspace settings win over a bot's own, then the defaults
- Pictures for bots and workspaces; bots editable from the header
- Coordinator tools: update_workspace, set_bot_workspace_instructions
Co-Authored-By: Claude Opus 5.5 <[email protected]>
- Serve each computer to its owner under /computers/<id>/ (HTTP and
websockets proxied to the AIO sandbox) and show it in a shared
ComputerView with browser, terminal and code modes, opened from the
computers modal or a take-over button in the thread.
- ask_user_to_take_over lets a bot hand a computer to the user for a
login or captcha; the message gets a take-over button and needs-you,
and the viewer hands it back with a chat message.
- While a task runs the thread shows "<bot> is working..." with the
task's latest step; steps read as plain words, not tool names.
- A coordinator with no workers no longer claims to delegate, and bots
describe started tasks in the first person.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
Drop the working-on panel. Rail rows show the bot's status line first.
The header's computer and model controls are ghost icons opening modals
that explain them, and the bot's text model, provider and computer show
under its name. The thread and composer are held to 760px.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
- Bots have a current computer (bots.computer_id), switched from the chat
header beside the model button or by clicking a computer the bot names
([computer:ID]); tasks run on it by default
- search_computers runs one read-only command on all of a bot's computers;
chat replies know their computers (compose-computers-note)
- The coordinator can use every computer and grants or revokes crew access
with assign_computer
- Delegated jobs record requested_by_bot_id; the worker's result or failure
is reported back in the coordinator's conversation
- bots_queue_updates records each model turn of a job, pushed live and shown
in the working-on panel
- Live relay: every process pushes new messages, job steps and bot changes
from the database to its own sockets, so work done elsewhere shows live
- Bot messages render as markdown (react-markdown + remark-gfm, no raw HTML)
with twui components; rail previews are plain text
- Fix header button overflow in the model and computer selects
- Bump @moduletrace/twui to 0.1.2
Co-Authored-By: Claude Opus 5.5 <[email protected]>
tbenandClaude Opus 5.5