Blerg 0.5.0 🎃 — the workspace release

Released just in time for Halloween: no tricks, only treats. 🦇

0.5.0 turns a Blerg session into a workspace: the files, a shell, the board and the chat side by
side, arranged the way you work, and fast to come back to.

Highlights

• A real workspace in every session. A project file explorer and viewer with syntax highlighting,
  line wrap and image zoom; split any two tabs side by side; a focus mode that maximizes the active
  tab; a tab row that scrolls with an overflow menu.
• A shell that behaves like one. The shell is a regular tab you can drag, split and theme. It
  survives bursts of output, switching sessions and page refreshes (with its last screen). On a
  desktop it lasts as long as the session by default, even with the browser closed; admins can set
  idle and lifetime limits.
• Instant switching. Coming back to a session shows the chat, files, explorer, panel and shell at
  once, at the scroll position you left, then refreshes quietly in the background.
• Command palette and quick open. Ctrl/⌘+K for actions, sessions, cards and files; Ctrl/⌘+P to
  open a file; an empty palette starts with what you can do in this session.
• Desktops you manage in one place. Account settings list your desktops; add one from any machine;
  engines installed later are discovered with a reason when something is missing.
• Boards closer to the work. Card keys like BLG-205, a Board button in the session, Assist sessions
  that start in the right place, and column management for agents with full access.
• Calmer usage limits. Usage meters warn at 80/90/95% (a slow pulse near the limit); orchestrating
  sessions get a heads-up so they shift work; "Resume when limit resets" works for every limit and
  engine.

Known limitations

• sudo doesn't work in a host shell. Blerg tracks every process a shell starts so it can end
  them all when the shell ends, and on Linux that tracking blocks programs that raise privileges.
  Use a terminal outside Blerg for sudo. Making this work is planned for 0.6.0.
• Updating Blerg ends open shells. After a server update a shell reconnects if it still can.
  Otherwise its tab says "This shell ended." with a New shell button. Shells that survive
  updates are planned for 0.6.0.
• Standard workspace storage has no size limit per workspace. Cluster workspaces now work on
  any cluster, in the storage class Blerg already uses, but nothing stops one from filling the
  node's disk. Workspace claims are kept until you remove them. For a hard limit, set
  WORKSPACE_STORAGE_CLASS to a size-limited class. Automatic cleanup is planned for 0.5.1.
• Cluster workspace sessions don't resume after their pod ends. Start a new session instead;
  the files stay on the session's claim. Resuming them is planned for 0.5.1.

Upgrade notes

• Reinstall the desktop daemon (install/desktop/daemon/install.sh install). It brings the shell
  output and scrollback changes, git-aware file search, desktop "busy" replies, usage notices, and it
  now refreshes the local-sandbox image when it was built from another commit.
• Runner migrations 092–096 run on start.
• The public repository no longer includes video/ (the maintainers' demo harness).

Full list of changes: CHANGELOG.md. What's next: ROADMAP.md. 🕸️

v0.4.5

Upgrade notes

• Reinstall the desktop daemon (install/desktop/daemon/install.sh install) for the sandbox homes below and for blerg-runner under Claude Code's own sandbox. A sandboxed session can no longer renew its engine's sign-in: keep Claude Code or Codex signed in on the machine (running it there refreshes the sign-in the sessions get). Sandboxed sessions started by an older daemon keep their old mounts until they end; stop them before you reinstall. If you ran Local sandbox sessions before this release, check ~/.claude/settings.json, ~/.claude/settings.local.json, ~/.claude/hooks, ~/.claude/plugins, ~/.claude/skills, ~/.claude/agents, ~/.claude/commands, ~/.claude.json (its mcpServers), ~/.codex/config.toml and ~/.hermes/config.yaml for anything you did not put there.
• The same daemon reinstall gives blerg-runner the dismissed exit code (4) for ask, review wait and review status; an older CLI reads a dismissed question as an empty answer and a dismissed review as a failure (exit 1).
• The same daemon reinstall gives blerg-runner in your sessions the new review-thread rules (your own resolve or reject stands unless the agent reopens the thread, your replies show in blerg-runner review list, and review reply <id> reopen). Until then an older CLI still lets an agent's answer at the same revision change a thread you settled, in the agent's own view; the browser keeps your status either way.

Added

• Dismiss in Needs you and the bell. A review request or a question you answered some other way (in the chat, say) no longer waits forever: Dismiss closes it at once, with an Undo toast for 5 seconds before anything is sent. A review request closes as dismissed (neither approved nor changes requested) and a question as dismissed (not answered); the agent is told in a Blerg system message ("The person dismissed the review request for ; they may have answered in the chat instead."), may ask again, and blerg-runner ask, review wait and review status exit 4 for a dismissal. Only the person can dismiss (the session's owner for a review request; whoever may answer for a question); the agent still closes its own questions with ask --resolve. History shows a dismissed item as "dismissed by you", and the bell now lists your pending review requests too (and drops one you decide or dismiss at once). A dismissal reaches the agent the way an answer does: queued while its desktop is away and sent again after a server restart. A question someone else dismissed says "Dismissed by another person". Dismiss is never offered on an engine's command approval (allow or deny those), and a dismissal still in its Undo time is sent when you close the tab or switch away. An engine that waited on the question (Codex, Hermes, native sessions) reads that it was dismissed, not a bare close. Runner migration 074 adds the dismissed state (@blerglab/chat 0.82.0).
• Card numbers in the checklist link to their cards and show when the plan is stale. A checklist item that names a card ("#155 Dismiss in Needs you"), on Plan and on Live's checklist line, gets the chat's treatment: once the card is confirmed on the session's one board, "#155" is an inline link with the card's hovercard, and a click opens the ticket dialog. Beside the item, the card's state glyph (✓ ◐ ○) shows when it differs from the item's own, for example an unticked item whose card is done. Until confirmed the text is drawn as written; a number with no such card stays text; the lookups are batched and kept, and the card states follow the live reads the pins use. Live's checklist line is no longer one button: a click anywhere still opens Plan, and its head is the keyboard's control. Every Plan item has a small chevron beside its title (aria-expanded) that shows the whole item from the keyboard; a click on the words still does.
• Ask a session to make a board. blerg-runner board create "<name>" [--repo R ...] [--template T | --columns A,B,C] [--description D] [--access read|file|full] proposes a new Board; nothing is created until you approve it. The proposal waits in Needs you, on Proposals and as a card in the chat, showing the name, description, repositories (the first is primary), columns or template, and the access the session asks for on the new board (Full by default). When you approve you can lower that access or give none, never raise it. Approving creates the board with your own authority (only an administrator can, signed in; Core issues a 30-second credential for that one approved board, and Board uses it once), then gives the proposing session, and no other, access to the board at the approved level, capped for a started session by its parent. Rejection or expiry creates nothing, approving twice creates one board, and "Allow for this session" never applies. Each proposal carries an idempotency key (--idempotency-key repeats one whose reply was lost). Sessions still never hold board administration; cron, restricted and board-started sessions cannot propose a board. Names, columns and descriptions with bidi or invisible format characters are refused. The session guide tells agents to use it when asked to "make a board for X" (@blerglab/chat 0.77.0: board proposals in the chat card; board migration 028).
• New board picks its repositories. The Board app's New board form lists the repositories your connected desktops have checked out (owner/name when the desktops agree on the folder's remote, else the folder name), several allowed, with a filter and a field to type one no desktop has; the first chosen is the board's primary repository. They are set as the board is created, so there is no trip to the board's settings afterwards. Templates work as before.
• "+ Add" in the Capabilities tab opens a plugin browser, and MCP servers that need a sign-in get a button for it. The browser lists every plugin of the marketplaces the session's engine knows (Claude Code and Codex), read by the session's daemon from the engine's own files: name, description, version, author, marketplace, and whether it is installed and enabled. It has a search, a marketplace filter, and an Install per plugin, which goes through the same owner-approved path as before (this session only, or always on). Adding a marketplace (a GitHub owner/repo or https://github.com/owner/repo URL the install allows) and entering a plugin by name stay as secondary actions; an engine with no catalog, or a sandboxed session, gets the add-by-name form. In the MCP servers list, a claude.ai connector that needs a sign-in has Connect, which opens claude.ai's connector settings in a new tab (restart the session after connecting); a server from your own settings (Claude Code's user scope, or Codex's global config.toml), in a session on your machine, has Sign in: Blerg asks the engine to start its own OAuth sign-in, shows the address the link goes to (in plain ASCII, with a warning when it uses international characters), and asks you to confirm the server, where it was defined and the address before opening it. "Your own settings" means your engine configuration on that machine, which an agent running there could also edit: only continue for a server you added. The sign-in returns to the engine on the machine that runs the session, the token stays where the engine keeps it, and the row turns connected when it is done. A server the project, a plugin or the session defined gets no link: sign in to it from a terminal. Sandboxed sessions say sign-in there is coming. Marketplaces added here are shared by everyone using that machine's engine. Only the session's owner can browse, add or sign in. A session's custom variables can no longer set HOME, CLAUDE_CONFIG_DIR, CODEX_HOME or XDG_CONFIG_HOME. Needs a daemon reinstall.
• Card numbers and commit hashes in chat messages are chips once confirmed. In a message, the agent's or a person's, #147 links to the card when the session's board is known (its one board) and the card exists there, and a 7 to 40 digit hash links when the session's repository confirms it is a commit (a read only the session's owner may make; others see plain text). A confirmed reference has the same hovercard as elsewhere, and a click opens the ticket dialog or the commit viewer. Until confirmed the text is drawn exactly as written, so nothing moves; "#1 priority" with no card #1, a hex word that is no commit, anything in a fenced code block and anything inside a link stay text, and an inline code span links only when it holds nothing but a hash. Lookups are batched (one pass every 60 ms, each reference asked once per session and kept) (@blerglab/chat 0.75.0).
• A README's HTML renders as on GitHub. Raw HTML in a markdown file (a centered banner, badges, a table of videos, a screenshot grid) used to show as literal tags; in the file viewer, the folder-file viewer and review mode it now renders through GitHub's allowlist of elements and attributes, sanitized by DOMPurify and rebuilt by React, with anything else (scripts, event handlers, styles, frames, forms, javascript: and data: links) dropped. In the viewer, a markdown file from the session's folder shows its relative images, read from the folder beside the file with the session's own access; a published file shows their alt text. Remote images (badges) are never fetched by themselves: each shows its alt text and Load image. Folder images load two at a time and retry while the server is busy, up to 50 per file before Load images. Relative links in a folder file open that file inside Blerg (in a published file they stay text), # links scroll to the heading, and external links open in a new tab. Chat messages, approvals, tickets, board cards and threads keep HTML as literal text, so nothing in them can be hidden from you; in review mode a document whose page does not show every word (an HTML comment, a closed sectio...

v0.4.4

Upgrade notes

• Reinstall the desktop daemon before starting Local sandbox sessions (install/desktop/daemon/install.sh install). The runner refuses every sandboxed start (launch sheet, board, cron, child) on a daemon that does not report sandbox_clones, with "update the daemon before starting Local sandbox sessions"; host sessions are unaffected. Stop running sandboxed sessions before you reinstall: the restart ends sandboxed Agent sessions as before, and a sandboxed Terminal session an older daemon started with your folder mounted is stopped when the new daemon reattaches (or, if its container is gone, not recovered), with a note in the session. A sandboxed session's work now lands on wip/<session-id> in your repository, not in your working tree: check out or merge that branch to use it. If you ran Local sandbox sessions before this release, check the .git/hooks and .git/config of those repositories for anything you did not put there.
• Existing "Always allow … on the cluster" rules now also cover your unsandboxed desktop sessions' cluster children (until now they could start pods only for cluster sessions). Review them in Settings → Sessions starting sessions. Sandboxed desktop sessions still ask for each cluster child unless the runner sets BLERG_RUNNER_SANDBOX_CLUSTER_CHILDREN=any (new; default once; see install/k8s/CLUSTER-RUNTIME.md).
• Desktop sessions can start cluster children (no migration). Reinstall the desktop daemon for the updated session CLI and guide (--runtime cluster from a desktop session, budget --runtime cluster). Desktop sessions launched before the upgrade have no recorded sign-in, so their first cluster child always asks on the card.
• Runner migration 071 records proposal deadline extensions (it applies on start; nothing to do).
• Runner migration 072 adds questions that do not wait (messages.no_wait; it applies on start). Reinstall the desktop daemon (or redeploy) for blerg-runner ask --no-wait / --resolve, the session guide line that tells interactive sessions to use it, and the marked delivery of a question's answer: a daemon older than this release passes the answer to the agent as plain text, which another person or a parent session could imitate. Questions are notified to the session's owner only (bell, toast) and send no phone push, because push subscriptions belong to no account.
• Runner migration 073 lets a board level a parent passed down to a child be stored without a sign-in of its own (created_via = 'parent'; it applies on start). Reinstall the desktop daemon (or redeploy) for blerg-runner session start --board and the cap shown by board access.
• Runner migration 070 gives every session board permission a level; existing filing permissions become File without asking. Reinstall the desktop daemon (or redeploy) for the updated session CLI (board access, board commands without a launch board) and the blerg_board session tool for Codex.
• Reinstall the desktop daemon (install/desktop/daemon/install.sh install), or redeploy, for the marked relayed decisions in Claude, Codex and native sessions, the owner-only Hermes approvals and their failure messages, and the batch review-reply wording in the session prompts and the managed ~/.claude/CLAUDE.md block. The daemon keeps a new private key, marker.key, in its state directory (~/.blerg-runner-daemon); a cluster pod with retained conversation history keeps it on that history's volume, so a replacement pod derives the same codes. Do not delete it: Claude Code records a conversation's system prompt, the code's announcement included, and a resumed conversation keeps that record until it is compacted, so after a new key every relay to a resumed Claude conversation carries a code the model was told is not Blerg's, and the agent treats real decisions as forged (it can still confirm them with blerg-runner review status or ticket status). A daemon that cannot keep the key says so in its log and uses an in-memory one, with the same effect after its next restart. Sessions started before this version keep the system prompt they were started with: their relays carry the marker, but the model is told about it only in new sessions or after a compaction.

Rolling back to 0.4.3

0.4.3 reads every live board permission as File without asking, so a board a person set to Read (or lowered to Propose) under 0.4.4 would file without asking again. Before starting a 0.4.3 runner on a database that 0.4.4 migrated, run this once against the runner database (on a database 0.4.4 never migrated it fails harmlessly: there is no level column):

UPDATE session_proposal_grants
   SET revoked_at = now(), revoked_reason = 'downgrade'
 WHERE kind = 'board_file' AND level IN ('propose', 'read') AND revoked_at IS NULL;

Board permissions at File without asking and Full keep filing without asking under 0.4.3, which is what they allow. A launch board that was lowered goes back to what its launch gave it (0.4.3 has no levels).

Rolling back to a build before children inherit board access

This applies to a rollback to 0.4.3 and to any earlier 0.4.4 build (one without runner migration 073). Such a build does not cap a child by its parent: it reads a child's board level as the child's own, and acts with the sign-in stored on it. Before starting it, end every board level a parent passed down and every level set on a started session, including children whose parent row was deleted (the delete clears parent_session_id, so a child is also known by how it was started):

UPDATE session_proposal_grants g
   SET revoked_at = now(), revoked_reason = 'downgrade'
  FROM sessions s
 WHERE s.id = g.session_id
   AND g.kind = 'board_file' AND g.revoked_at IS NULL
   AND (g.created_via = 'parent' OR s.parent_session_id IS NOT NULL
        OR COALESCE(s.delegation_via, '') <> '' OR s.started_by_kind = 'session');

Run it together with the block above when going back to 0.4.3. Started sessions then have no board access until you give them levels again.

Added

• Children inherit board access. A session that starts another one passes board access down with the start: blerg-runner session start --board <name|id>:<level> (read, file or full; repeatable), never above its own level for that board. The approval card shows it ("with Blerg · Full"); a rule or grant can start such a child too, and the start is checked against the parent's levels again when it runs. No credential is minted: the child gets a level of its own and its board calls go through the runner with its own session token, acting with the parent's sign-in, on the desktop and the cluster, sandboxed or not. Every call is capped by the parent's level at that moment, so lowering or revoking the parent lowers every child at its next call, and a child never exceeds its parent even if the parent is raised later. The child's Permissions dialog shows each level with the cap; you can lower a single child, and raising one above its parent is refused. The child gets the same "Board access changed" note, the parent's changes included. Its access ends when the parent is stopped for good, a kept-running child included. Child-start rules and session grants you gave before this release also cover starts that pass boards (the child never gets more than the parent). A desktop child cannot file proposals yet (it has no recorded board sign-in), so File without asking gives it only Read in practice. Each child has its own board limits (4 calls at once, 240 requests a minute, 20 filings an hour without asking), bounded by 3 running children per parent and 6 per account (@blerglab/chat 0.35.0).
• A pinned board card shows the live card. A Blerg Board card the agent pins (blerg-runner pin with "source": "blerg-board", its board_id and "key": "#<number>") is shown in the session panel's chip and ticket dialog as the board holds it now, read with your own board permissions through the runner (GET /api/board-cards/{board}/{number}): its column, type, priority and tags, where it was filed from, its repos and its trail, with a live mark, and a note when the agent pinned it in another state. Move works in place (as your role on the board allows); Run, Discuss and Archive open the card in the Board. When the board cannot be read, the dialog shows the agent's copy and says so. The runner sets the card's address itself (the Board's page, never a link the agent wrote), and blerg-runner ticket get, ticket create and ticket file print the card's address and a ready pin line. blerg_card_get takes with_trail (column name, columns and the latest 30 trail events in one call). Pins from other trackers keep their dialog, now one column with the details as chips instead of a Details box. The ticket dialog takes min(1400px, 94vw) like the file viewer, keeps its text at a reading width, and has Maximize (⤢ / Ctrl+Alt+F), remembered like the viewer's (@blerglab/chat 0.34.0).
• Questions that do not block the agent. blerg-runner ask --no-wait "<question>" puts a decision that belongs to you in the session's Needs you and the bell ("Question · not blocking"), and the agent keeps working. Answer it there or on its card in the chat: the answer is recorded like any answer and reaches the agent at its next step as a message naming the question (Answer to your question <id> ("…"): …). A message you type in the chat is never taken as its answer; if you answer that way, the agent closes it with blerg-runner ask --resolve <id>. Only the session's owner answers one, a daemon restart leaves it open, and a session started with the runner key cannot post one. An answer the agent can never be sent (for example, too long to send with its question) is tried three times; then the session says so, and you send it as a message. A delay (a busy session, a full queue, a database error) is retried until i...

v0.4.3

Local models in the cluster, agents that work together, and permissions you can see.

• Hermes in cluster pods with a shared provider config for your own model servers (e.g. NVIDIA Nemotron on vLLM), shown as local in budget.
• Child sessions on the cluster: a cluster session can start other agents as pods, with approval cards and rules.
• Board access from desktop sessions, and Run this card can target your desktop sandbox. New boards run as their creator; existing ones are one click (Run as me).
• Proposals and review requests in the chat: approve a filed card or a reviewed diff right where the agent asked, and the agent is told the outcome.
• A Permissions dialog with search, for child sessions, board filing and MCP write tools, also available when launching a session.
• First run asks for your account instead of logging a generated password.

Full notes below.

Upgrade notes

• Desktop: reinstall the daemon (install/desktop/daemon/install.sh install) for the new CLI commands (models, review request, ticket status) and the child-session guide; rerun ./blerg-up.sh so it adds BLERG_CORE_BOARD_MINT_KEY.
• Kubernetes: rerun ./deploy.sh; it adds the mint key, and optionally stores HERMES_PROVIDERS_FILE as the shared Hermes provider config. Runner migrations 064–069 and the new core and board migrations apply on start.
• Run as me needs one new secret, BLERG_CORE_BOARD_MINT_KEY, on core and the board. ./blerg-up.sh adds it to an existing .env and install/k8s/deploy.sh to an existing blerg-secrets; with neither re-run, boards keep working and take a pasted token as before. Core migration 022, board migration 024.
• An existing install keeps its accounts, and setup mode does not open on it, because an account exists. That includes an install whose generated admin never signed in: its one-time password is still the one printed next to BLERG_BOOTSTRAP_ADMIN_PASSWORD in that first boot's log, if you still have the log. Otherwise reset it: on the desktop ./blerg-up.sh --reset-admin; on a cluster kubectl -n blerg exec deploy/blerg-core -- /blerg-core users set-password --subject <username> (look up the username with the psql query in install/k8s/README.md, "First login").

Added

• Run as me: a board's sessions run as you in one click. Board settings → Automation has a Run as me button that has core mint a run-sessions token for you and saves it on the board, with no copy and paste; the create-board form has Run this board's cards as me checked (BLERG_BOARD_DEFAULT_RUN_AS_CREATOR, default true; a multi-tenant operator may set false); and a board with no token offers it beside Run this card, after which the run-target chooser appears for you. Run this card now works out of the box on a single-user install. The token is listed in core Settings → Agent tokens as "Board automation" (minted by board ) and can be revoked there; replacing or removing it, or deleting the board, revokes it. Pasting a token stays available (Use a different token…). The board never sees your core cookie, and for this it uses a dedicated key rather than core's internal key: it presents (BLERG_CORE_BOARD_MINT_KEY) that opens only this mint and its revoke, and core requires your own live browser session, refusing agent, session and daemon tokens, another account's, and more than 10 attempts an hour.

• Hermes agent sessions discover named model providers, preserve explicit provider selection through switches and native recovery, and keep local-budget claims conservative across configured targets.

• Live → Session lets owners enable or revoke child-session approval across currently available engines for the parent session, with separate sandbox and unsandboxed permissions and explicit standing-rule disclosure.

• Checklists show current work and explicit native-subagent or child-session assignments, with stable item references that survive rename and reorder.

• Hermes agent sessions use the native streaming gateway for tools, steering, questions, plans, children, background process inventory, model capabilities and token accounting, with exact native host-conversation recovery and explicit unsupported-runtime limits.

• Document local vLLM setup for Hermes, local-budget checks, sandbox reachability and child-session permissions.

• A session running on the cluster can start child sessions that run as cluster pods (blerg-runner session start --runtime cluster, the default there), with the same approval card ("on the cluster", chat 0.27.1), rules, session grants, budget, child routes and discard cascade as desktop children. Cluster rules and grants are separate from desktop ones; a desktop session still cannot start a cluster child.

• Hermes sessions on the cluster can use the operator's own model servers: set HERMES_PROVIDERS_FILE in install/k8s/.env to a Hermes provider fragment, and every Hermes pod merges it into its configuration, the cluster launch sheet lists those servers' models with the same IDs as on a desktop, and Hermes counts as local hardware when every endpoint is private and keyless. The example session NetworkPolicy gains an opt-in rule for reaching those servers.

• Proposals show in the session's chat as a card (chat 0.28.0): Approve, Edit (the draft editor in a sheet), Reject, or Allow for this session, which also approves the session's later proposals of exactly that scope (one board, or one connection's one tool). A created card follows as a compact ticket with Open, and becomes a chip in the History tab. The Proposals page stays the inbox, and a decision in either place is the same decision.

• One Session permissions block in Live replaces the separate child-approval checkboxes and the child-permissions row: toggles for starting children, filing cards on a board and running an MCP write tool without asking, and every permission in force with a styled Revoke. The launch sheet's Permissions gives the same ones before the session starts. Session permissions are owner-only, end with the session (and with a parent's discard), are refused for cron, restricted, board and agent-token sessions, and every automatic approval goes through the person's own approval path and records the permission that allowed it. A permission approves at most 20 proposals an hour (BLERG_RUNNER_GRANT_HOURLY_CAP), an MCP-tool permission stops when the tool's definition changes, and the same draft filed again within 15 minutes returns the earlier filing instead of a second card. Needs the updated session CLI for ticket file to report a card filed at once.

• Session permissions move into a Permissions dialog with a search: child sessions, board filing (a checkable list of your boards with a selected count and Select all shown), MCP write tools grouped by connection, and everything active with how and when it was given. Changes apply on Save with a one-line summary ("Grant 2, revoke 1"); the dialog is keyboard-first and a full-screen sheet on a phone. Live → Permissions is now a compact summary: the active count, Manage, and a chip with × per permission. The launch sheet's Permissions… opens the same dialog and counts what it will give. The proposal card's link now names Permissions (chat 0.29.1).

• A session can ask its owner, explicitly, to approve a file or diff it published: blerg-runner review request <name> --ask "..." [--wait], or publish/diff ... --request-review "...". The request is pinned to that version (a newer version supersedes it) and shows as "Review: " under Live → Needs you and a card in the chat; the viewer gets a bar with Approve and Request changes (chat 0.29.0). Only the session's owner, signed in, decides; the decision, with the comments made on that version, reaches the session as a message or its waiting command. Runner migration 069.

Fixed

• Decisions Blerg relays to an agent (a review request's outcome, a proposal's outcome) show in the chat as a Blerg note, not as the person's message (@blerglab/chat 0.29.2).
• A session's first prompt is recorded as written by whoever started the session: a board's card run or board session as the Board, a child's task as its parent session, a cron's prompt as the Cron. The chat draws it under that author, never as You, such a message never answers the agent's open question, and Insights no longer counts it (or a relayed decision) among the person's messages; a person's own launch is unchanged (@blerglab/chat 0.29.3). Sessions started before the upgrade keep what was recorded. No daemon update is needed: daemons since 0.3.0 honor the spawn frame's initial_prompt_source, and an older one records the prompt as the person's, as before.
• Codex sessions in a cluster pod with native conversation history get their login again, and Claude Code sessions there can write their settings: the history mounts under ~/.codex and ~/.claude made the container runtime create those directories as root, so Codex could not write auth.json ("permission denied") and its app-server kept failing. The pod now prepares each engine home as an agent-owned, pod-ephemeral directory; the login and config stay off the history volume.
• A child session's model is resolved against its engine's catalog where it will run: a routing id, a display name or a unique part of an id is accepted and recorded as the routing id, and an unknown or ambiguous name is refused with the available models (blerg-runner models lists them), instead of a child that fails on a made-up model route.
• A session running in a cluster pod can start child sessions and read blerg-runner budget again: the server recognized a cluster parent only while it sat on the placeholder cluster daemon, which its own pod replaces as soon as it connects, so every start was refused with "children run on the parent's desktop daemon". Cluster rules, grants...

v0.4.2

Upgrade notes

• Desktop: reinstall the daemon and rebuild the sandbox image (docs/sandbox-image.md) so sandboxed
  child sessions can commit in Git worktrees and have Go; existing containers keep their old image.

Fixed

• A child session drawn under its parent in the sidebar no longer repeats "from {parent}".
• A sandboxed child session reports its runtime as docker (it said daemon).
• Child-session rows show the token unit once and one clearly labeled revoke control per engine, runtime and desktop.
• Allowing child starts for a session covers every repository, including no repository, on the approved engine, runtime and desktop; duplicate permissions are consolidated without losing their audit records.

Added

• Explicit child-session discard stops and archives workers from the CLI, panel and sidebar while preserving history, Insights totals and direct URL access. Children stay in a stable list until discarded.
• Sandboxed coding children can commit in linked Git worktrees and run Go builds/tests with the default image; shared Git metadata is validated and mounted without adding host Git push credentials. The default sandbox now includes Go 1.26.9 alongside Node.js 22.

v0.4.1

Added

• Attachments show local image, first-page PDF and text previews before sending; document formatting uses accessible icons with active states (chat 0.26.0).

• Document reviews support rendered Markdown editing, tracked/clean views, and passage-linked margin comments with Ctrl+Alt+M. Image markup supports selectable annotations with comments, style editing and visibility controls (chat 0.25.0).

• Resolved and rejected code review threads can be collapsed individually or hidden together.

• Code review opens directly beside patch lines, with inline threads, general comments, Markdown previews, code suggestions and resolved/rejected replies carried across revisions (chat 0.24.0).

• Mermaid diagrams and inline-data Vega-Lite charts render in chat, Markdown and the file viewer, with native chat colors that follow theme changes, source, copy and zoom controls (chat 0.23.1).

• Request code changes on selected diff lines in a session, with desktop and phone selection and the existing review reply flow (chat 0.23.0).

Fixed

• Reopening a document or code review thread requires a new comment, included with the original request and prior answers when sent to the agent (chat 0.26.2).
• Markdown and PDF reviews support collapse, Hide resolved and Reopen, preserving reply history and original passage anchors (chat 0.26.1).
• A browser could be signed out after waking with several Blerg tabs open.

v0.4.0

Upgrade notes

• Reinstall the desktop daemon for child-session recovery and local-engine reports; start a new
  session to receive the updated CLI guide. Chat is 0.22.0.

Added

• Add permitted plugins and bundled skills from a session’s Capabilities panel, with human-approved agent requests and between-turn loading for supported host Claude sessions.

• A session can start and drive other sessions on its desktop with your approval
  (blerg-runner session …), with children in Live, the sidebar and Insights (chat 0.22.0).

• blerg-runner budget reports the desktop's remaining capacity separately by provider.

• Propose Board cards from Claude or Codex sessions, with editable approval drafts, verified source metadata, and optional administrator-only card details.

• Choose a Board when launching a session, with verified access, shared MCP/CLI tools, and matching cron board discovery.

• Session and subagent progress bars show native plans or explicit blerg-runner progress counts, with each caller kept separate.

• A "vX.Y.Z available" link beside the version in the runner sidebar, core footer and board top bar when a
  newer public release exists, linking to its GitHub release page. Core checks api.github.com every 6 hours
  (the check shows the server's IP to GitHub); BLERG_UPDATE_CHECK=0 turns it off, BLERG_UPDATE_REPO
  changes the repository.

Fixed

• Authenticated messaging CLI requests refuse redirects, preserving session and board credentials.

• Keep long shell commands and results compact in the session panel, with scrollable full text and visible status and actions.

• Codex subagent typing stays separate from the main reply, and a completed subagent message no longer makes the main agent's unfinished text disappear.

• Ctrl+A (Cmd+A) with a file, code or ticket open over the page selects what is in it, ready to copy,
  instead of the whole page behind it; a text field keeps its own select-all (chat 0.21.1).

• A bare file name the agent mentions (plan.md, no folder) that is a file published in the session
  opens that published file, instead of looking for it at the top of the session's folder and saying
  "Not found" (chat 0.21.2).

v0.3.1

Upgrade notes

• Desktop: reinstall the daemon (./daemon/install.sh install) so a background shell command shows its
  command line in Running now; until then it shows its description, as before.
• Chat (@blerglab/chat) is 0.21.0, with a new theme token --chat-font-display (section headings;
  a theme that does not set it gets a condensed system face); commitUrl is accepted but no longer used (commit chips stay in
  Blerg: they open the item's diff or copy the sha).

Added

• On a touch screen, holding a message, code block, ticket card or checklist row opens a sheet with
  Copy message, Select text and Cancel; the always-visible Copy buttons are gone there (desktop keeps
  the hover button). Nothing is selected by the hold itself, and Select text opens the text full
  screen, all of it selected with the phone's own handles, with Copy (the part still selected) and
  Done.
• blerg-runner checklist remove <n|--text …> drops one checklist item; the other items keep their
  ticks, commits and diffs (before, removing one meant setting the whole list again).
• A published diff of one file with 20 or fewer changed lines shows its hunks in its card, colored
  and numbered like the diff viewer, with View kept.

Changed

• The session panel's Live tab no longer has an MCP servers section; the Capabilities tab's MCP servers
  group shows each server's status as it is now (connecting, connected, failed, needs sign-in, disabled).
• Live's one-line summary is two controls: the ticket chip opens the ticket over the page, the checklist
  part goes to the Plan tab.
• The checklist's progress bar is a short rounded bar beside the count (green when done), not a thin
  line across the panel.
• A background shell command in the panel's Running now reads as a command: a >_ glyph, the
  command in monospace (the full text on hover), what it is for, and shell, elapsed and status
  chips, with no model or effort. Subagents get an agent glyph. The daemon now sends the command
  with the task's start (reinstall the daemon; older starts show their description).
• The Files list is compact: one ~28 px row per file with a glyph for its kind, the name, and a muted
  size, version, time and "you" (for files you attached); Download and Delete are small icons that
  show on hover or focus (always on touch), and clicking the row opens the file. Past six files a
  filter box, a sort (newest or name) and an origin choice (all, from the agent, from you) appear,
  and are remembered per browser.
• The file viewer colors code and JSON: a .go, .ts, .py and so on opens as numbered, colored
  lines, and JSON is pretty-printed and colored (the start of a very large file; the rest plain).
• A CSV or TSV is one table style in the viewer and in the inline preview (borders, header row, zebra
  rows); the preview is the first rows and columns of the same table.
• Markdown files (inline preview, viewer, the review page) read like a README: system UI font, ruled
  headings, code chips, padded code blocks, bordered zebra tables. Chat messages keep their compact
  scale, with the code chip, table, and quote refined to match (chat 0.18.0).
• A pinned ticket reads like an issue in a tracker. Its status chip is tinted by meaning (gray to do,
  blue in progress, amber blocked, green done, faded and struck through when canceled) in the chat,
  the modal and the session panel. The chat's card is a summary: key, status, title, one line of type,
  priority and assignee, the start of the description and Open ticket. The modal has the
  description, the acceptance criteria, the comments with avatars and a Details column (chat 0.19.0).
  It is laid out like the Board's card sheet: uppercase section headings split by hairlines, Details
  as a panel of label/value rows, acceptance criteria as a list of boxes, comments as boxed entries
  on a trail, and Open in … as a button beside Close; on a phone the title takes the full width.
  A P-scale priority (P0 to P4, also "P1 - Critical") gets the same ↑ → ↓ glyph as High, Medium and
  Low (chat 0.21.0).
• A checklist item shows its commits' short shas directly (three, then "+N more") instead of an
  "N commits" toggle. With the item's diff, a sha opens it in Blerg's diff viewer at that commit;
  without one it copies the sha. ± View diff is a real button with the diff's +/− counts. Commit
  chips, the History tab's too, no longer link to GitHub or another forge; commitUrl is accepted
  and unused (chat 0.19.0).

Fixed

• Pasting code copied from a web page into the message box, inside a code fence you typed, no longer
  fences it a second time: inside an open fence the text goes in as copied. A code block copied from
  GitHub keeps its language on the fence.
• The card of a published diff shows its summary again ("6 files · +58 −11" and the file names); in the
  app it was squashed to a thin line because the image-preview style won over it (chat 0.17.2).

v0.3.0

Upgrade notes

• Desktop: reinstall the daemon (./daemon/install.sh install). 0.3.0 needs it for opening session
  files, MCP connection tracking and the first-message wait, Codex plan updates, background-task
  reconciliation, child effort reporting, the shared command guidance for Codex sessions, and the
  session guide lines that ask agents to pin their ticket, keep a checklist and publish diffs. The
  blerg-runner CLI itself updates with the checkout and works under an older guide; until the
  reinstall, the panel simply has less to show.
• Runner: migrations 053 to 058 (cron engine, latest capabilities, checklist/ticket/plan and MCP-status
  indexes on agent_events, account_preferences) run when the server starts. No manual step.
• Chat package: @blerglab/chat is now 0.17.1. An app that embeds it takes the new version from the
  runner's manifest and installs it (Install); ChatView's
  onViewCommitDiff (0.15.0) is removed, and a side panel that drew checklist "View diff" passes
  onViewDiff(artifactId) instead. A proxy that serves the board's chat may add the optional
  GET {prefix}/preferences route for code colors.
• Contributors: Go database tests need a Postgres user with CREATEDB
  (CONTRIBUTING.md).
• New optional setting: BLERG_RUNNER_MCP_PROMPT_WAIT_S (default 30; 0 turns the first-message wait off).

Added

• Chat (@blerglab/chat 0.12.0 to 0.17.1, now 0.17.1):
  • Code blocks are syntax-colored (a lazily loaded highlighter; diff lines colored) and, over 25
    lines, show 15 with Show all and an Open viewer with line numbers; a pasted message over 25 lines
    compacts the same way. Markdown, text, code, JSON, CSV and PDF files get small inline previews
    (size-capped, fetched when scrolled into view). (0.12.0)
  • checklist rows and ticket cards in the transcript; the checklist, the engine's plan and the
    pinned tickets in LiveState. (0.13.0)
  • Code color themes: codeThemes, applyCodeColours and friends, and six new code tokens
    (variable, built-in, operator, text, background, line numbers). (0.14.0)
  • MCP and checklist commits: slots.aboveComposer, commitUrl, McpHoldLine, CommitChips,
    mcp_status helpers. (0.15.0)
  • Diffs and file links: DiffView, the diff view, parsePatch and friends; canOpenWorkspaceFiles,
    files.workspaceFile, workspaceFromCode/workspaceFromHref. (0.16.0)
  • Rich copy and paste: every message has a Copy button that copies its Markdown source and its
    rendered HTML; selecting text in the chat and copying keeps headings, lists, links, tables and code
    as Markdown plus sanitized HTML (card chrome left out); and pasting rich HTML into the message box
    inserts it as Markdown (code language kept, images and scripts dropped), with Ctrl/Cmd+Shift+V
    still pasting plain text, as does a very large or deeply nested paste. See Copying and pasting.
    (0.17.0)
• Diffs. blerg-runner diff [<range> | <commit>... | --staged | --worktree] [--title T] [-- <paths>]
  runs git in the session's folder (hooks, filters, external diff tools and text conversions of the
  repository never run) and publishes the patch as <title>.diff; .diff and .patch files get the
  view diff, a card that says "N files · +a −d" with the first names, and a diff viewer (file list,
  unified or side by side, line numbers, folded context, the code colors, Copy patch). The session
  guide names the command. See Diffs.
• Clickable file links in the chat. A relative link or a path in inline code in the agent's text
  (README.md, src/a.go:120, docs/a.md#L12) opens that file from the session's folder in the
  viewer, scrolled to and marking the line when one was named, with Copy path, Download and
  Save a copy to Files. Only human session owners (and administrators, for sessions that are not
  private) can open these files, through the daemon, with traversal, symlink, file-identity and
  secret-file protections. See Files the agent mentions.
• Settings. A Settings entry under Insights in the left bar (a tab on a phone) opens a dialog over
  the current page; it holds Show thinking and Compact tool calls, which left the session panel (same
  per-browser keys, so earlier choices carry over), the code colors below, and a link to Blerg's main
  Settings. The session panel's Settings section is gone; Resume when limit resets, which belongs to
  one session, sits in its Session section.
• Code colors. Settings has a Code colors section with ten themes
  (Blerg, GitHub Dark and Light, One Dark, Dracula, Monokai, Solarized Dark and Light, Nord, Gruvbox
  Dark), one for dark mode and one for light, per-color changes under Customize, and a live preview of
  real code blocks (ts, go, python, json, diff). The choice is kept per account on the runner
  (GET/PUT /api/me/preferences, migration 057 account_preferences) and cached in the browser. The
  chat's code blocks, viewer and file previews wear it, in the runner and in the board (which reads it
  through its chat proxy, GET /api/chat/preferences, and the runner's GET /api/runner/preferences;
  the board has no editor).
• The session checklist and pinned tickets. blerg-runner checklist set|add|tick|untick|clear keeps
  a checklist of the session's work; blerg-runner pin <file.json> pins a ticket from any tracker
  (JIRA, Bugzilla, GitHub, GitLab, Linear, a Board card, …) in one source-neutral shape, and
  blerg-runner unpin takes it off. The chat draws a compact checklist row and a ticket card (a re-pin
  says what changed); the session panel shows them above the engine's own plan. checklist tick|add --commit <sha> names the commits that finished an item (a commit chip per item, linked when the
  repository is known) and also publishes the diff of those commits; the chip gets View diff. New
  routes POST /api/sessions/{id}/checklist and /tickets (the session's own token); GET /live gains
  checklist, plan, tickets and ticket. Migration 055 adds three partial indexes on
  agent_events. Pinning copies the ticket's text into the session.
• Engine plans in the session panel. Claude Code's own task list and Codex's native plan updates both
  appear as Plan when the agent set no checklist.
• MCP servers in the session panel and Send now. Claude and Codex MCP connection state is tracked
  natively, with durable live snapshots. The Live tab gains an MCP servers line ("Connecting 2 of
  3…", then "2 connected · 1 failed · 1 needs sign-in") that opens to each server's state, source and
  tools; the first message is held for up to 30 seconds while the servers connect, the chat shows
  "Waiting for MCP servers before sending your first message · 0:12 / 0:30 · Send now" above the
  message box, and the session's owner can send it at once (a release_held_prompt message; GET /live gains can_release_prompt).
• Reported child configured effort in chat, Live and Insights, with explicit unknown values.
• Adapter-specific tool-definition refresh guidance in capabilities and tool-change review.
• Target-scoped engine/model/effort discovery for browser, REST and MCP callers, including
  existing-session catalogs and dynamic launch, cron and Board engine choices.
• Board role/card effort settings, effective native session metadata and backend-qualified
  recovery; engine changes clear future-launch overrides while preserving existing sessions.
• Published artifact links can open the chat viewer directly through a trusted session mapping.

Changed

• The session panel has a Plan tab (Live, Plan, History, Files, Capabilities): pinned tickets,
  the checklist or the engine's plan, and the session's published diffs move there, and Live keeps one
  summary line ("Checklist · 18 of 23 · Next: ...") that opens it, so a long checklist no longer pushes
  Needs you and Running now off screen. The tab shows only when there is something for it.
• Go test suites run packages in parallel with isolated template-backed PostgreSQL fixtures and
  shorter injected test waits (the runner suite takes about 3 minutes, down from about 10); database
  test users need CREATEDB. Fixtures safely clean abandoned helper databases; OAuth, Codex timeout and
  webhook tests use controlled clocks and wait for asynchronous work before teardown. Stale Claude
  idle timers no longer close a newly rearmed idle window.
• Agent-facing launch guidance uses target-scoped engine/model discovery instead of unscoped catalogs.
• Engine integration metadata, customization roots, managed credential access modes and
  restriction/limit capabilities use shared registries with explicit adapter boundaries.
• REST/MCP and embedded proxies share model controls and optional durable message IDs.

Fixed

• The "Couldn't sign you in · Retry" banner on the board and runner heals itself. After a power cut
  or an outage it used to stay until the person pressed Retry; it now tries the quiet hidden-frame
  renewal when the network comes back, when the tab is shown, and on a 5 s, 15 s, 30 s, 60 s, then
  two-minute backoff (paused while the tab is hidden, one attempt at a time), and a token takes it
  down with no page reload (the runner reconnects, the board reloads its data). When core answers
  that the sign-in has ended, the banner says "Your sign-in has ended · Sign in" and stops trying;
  for that core now sends a renewal frame whose sign-in is gone back to the page's own
  /silent-refresh.html with #signin_error=<reason> instead of to its login page. Automatic
  full-page redirects to /auth/refresh stay bounded exactly as before.
• A long checklist item wraps beside its box instead of dropping the whole text onto the next line.
• The session panel's "Resume when limit resets" ...

v0.2.1

Upgrade notes

• Reinstall the desktop daemon to get the connection check: git pull, then
  ./install/desktop/blerg-up.sh (or ./install/desktop/daemon/install.sh install). Until then a
  0.2.0 daemon keeps working against a 0.2.1 server exactly as before (it is sent nothing new).
• Server and daemons can be upgraded in either order. A 0.2.1 daemon against a 0.2.0 server logs
  daemon: link to … open for 5s but not confirmed by the server and install.sh status shows
  unconfirmed; that is expected and fine. Session pods pick the change up with the new runner
  image; nothing to do.
• install.sh install (and blerg-up.sh) now exits 6 when the server refuses the daemon
  token. Before anything is replaced the running daemon is left alone; after the restart the new
  daemon is installed but refused. Fix BLERG_RUNNER_DAEMON_TOKEN in install/desktop/.env to
  match the server's and run it again. A daemon with a wrong token now retries once a minute (it
  used to retry every 2 s) and logs one daemon: REFUSED: line.
• Files are larger now: 100 MiB per file (was 25), 500 MiB of attachments per session (was 200),
  and a new 1 GiB total for the files one session's agent publishes (there was none). Check your
  runner data volume size (Kubernetes blerg-runner-data, RUNNER_DATA_SIZE, default 10Gi;
  desktop: the blerg-desktop-runner-data Docker volume, on the disk Docker uses) against the
  sessions you keep, or lower the limits with BLERG_RUNNER_MAX_FILE_MB,
  BLERG_RUNNER_MAX_SESSION_UPLOADS_MB and BLERG_RUNNER_MAX_SESSION_ARTIFACTS_MB.
• Kubernetes: re-apply the manifests (deploy.sh). The ingress body limit goes from 100m to
  128m so a 100 MiB file fits; a controller other than ingress-nginx needs the same change by
  hand. The three limit keys are wired, optional, in runner-deployment.yaml.

Security

• Go 1.26.9 everywhere the build picks a Go: every go.mod and go.work, the Dockerfiles (pinned
  by digest), the CI jobs (which now read the version from go.mod), the desktop installer's host
  and container builds, and the session images, whose Go toolchain is copied from the devcontainer
  build and so moves to 1.26.9 too. This picks up the standard-library fixes released since
  1.25.14; govulncheck reports nothing reachable in any module. golang.org/x/crypto moves to
  v0.56.0 in core and runner.
• core/web test tooling moves to vitest 4, which clears the npm audit findings in its
  development dependencies (they never shipped in the built app).

Added

• The daemon keeps the state of its connection (connecting, connected, unconfirmed,
  refused) in ~/.blerg-runner-daemon/connection.json (mode 0600, no token), and
  install/desktop/daemon/install.sh status prints it.
• GET /api/daemon/whoami on the runner: checks a daemon token without connecting a daemon
  (200 {"ok":true,"mode":"daemon"|"runtime"}, otherwise 401).
• Desktop: install.sh install (and blerg-up.sh) asks the server whether it accepts the daemon
  token from install/desktop/.env before it replaces the running daemon. A refused token stops it
  with exit code 6 and leaves the running daemon as it was; an older server (no such check) or a
  server it cannot reach only gets a note. After the restart it waits up to 30 seconds for the new
  daemon to report its connection and stops with exit code 6 when the server refused it; then
  blerg-up.sh exits 6 as well. Troubleshooting: install/desktop/DAEMON.md, "Is the daemon
  connected?".

Changed

• The session panel no longer repeats what is a click away: its Session section drops the Insights,
  Files and Capabilities links (the header's Insights button and the panel's own tabs open them),
  and on a wide screen the panel drops its own close button (the header's panel toggle opens and
  closes it). The drawer on a narrow screen keeps its ✕.
• The desktop installer uses a host Go only if it is 1.26.9 or newer; otherwise it builds the
  daemon in a container, as before.
• make lint refuses a golangci-lint other than the version CI pins (v2.13.1), and
  scripts/check_lint_pin.sh (run by CI) keeps the Makefile and the workflow on the same version.
• Removed runner/Dockerfile.daemon and the make docker-build-daemon target: the image could not
  build (it needs the repository root as context) and nothing used it.
• Runner: the file limits are configurable (BLERG_RUNNER_MAX_FILE_MB,
  BLERG_RUNNER_MAX_SESSION_UPLOADS_MB, BLERG_RUNNER_MAX_SESSION_ARTIFACTS_MB, whole MiB; an
  invalid value keeps the default and logs one line; a per-file limit above a session total is
  lowered to it, also with one line) and passed through by the desktop compose
  file, the Kubernetes ConfigMap and the .env examples. The runner reports the limits in force as
  limits (max_file_bytes, max_session_upload_bytes, max_session_artifact_bytes) in
  GET /api/sessions/{id}/files, GET /api/runner/sessions/{id} and the browser's
  initial_state, so clients can refuse a file that is too big before sending it. A declared size
  over a limit is refused before the body is read; the 413 names the file's size and the limit.

Fixed

• The Claude usage meter works on work and enterprise accounts. Their usage answer has no
  five-hour or weekly window, only a monthly spend limit, so the Claude row used to vanish. The row
  now shows "month" (Monthly spend limit) with the share used, "<1%" while under one percent, and
  "capped" once the limit is used up. A subscription with extra usage switched on shows it beside
  5h and week. Only the percentage leaves the machine, never an amount, limit or currency. Update the
  runner server (it carries the web app) and reinstall the desktop daemon: an older server ignores
  the new window.
• Lint passes again under Go 1.26: two //nolint:gosec comments in the runner's artifact code
  that the linter now reports as unused are gone.
• TestCookieSecureFlag models Safari's cookie rule itself. Go 1.26's cookie jar sends a Secure
  cookie to loopback addresses over http, as Chrome and Firefox do, so the jar no longer stood in
  for Safari. The login code was right and is unchanged.
• Desktop: a fresh install can store files. The runner image runs as an unprivileged user
  but shipped no /data, so the data volume was created owned by root and every publish and
  upload failed with "storage error". The image now ships /data owned by that user, and a
  one-shot service in the desktop compose file (blerg-runner-data-init, reusing the postgres:16
  image) repairs a volume an earlier install left behind, keeping its files. The runner also logs
  one STORAGE NOT WRITABLE line at startup, naming the directory, the user id, the error and the
  fix, when it cannot write to its data directory (it still starts).
• Desktop: container sessions and the stack work behind a corporate proxy. Docker copies the
  proxy settings of ~/.docker/config.json into every container, which sent calls to
  blerg-runner and blerg-board to the proxy. Sandboxed sessions now get NO_PROXY and
  no_proxy as the union of the daemon's, your Docker client config's and Blerg's own service and
  loopback names (the proxy settings themselves are left alone), and the core, board and runner
  services of the desktop compose file list the service names as exceptions, keeping your own
  NO_PROXY and the noProxy of your Docker client config (blerg-up.sh passes it on).
  Reinstall the daemon and start new sessions for this to apply; see
  install/desktop/DAEMON.md ("Troubleshooting the stack").
• The daemon no longer says it is connected when the server refused its token. It logged
  daemon: connected to … as soon as it had sent its hello, and the server answered a wrong token
  only by closing the connection (4401), so a reinstall that kept a stale token looked fine. The
  server now confirms an accepted daemon with a daemon_welcome message (sent only to a daemon
  whose hello asks for it, so a 0.2.0 daemon sees nothing new; a session pod's carries its
  session), and the daemon logs connected only on it. Against a 0.2.0 server, which sends none,
  a connection that stays open for 5 seconds is taken as accepted and logged as not confirmed. A
  refused token is one loud daemon: REFUSED: line that says where the token comes from (for a
  session pod: its runtime token), and it no longer resets the reconnect backoff: a refused daemon
  slows to one try a minute instead of retrying every 2 seconds.
• Desktop: blerg-up.sh --no-daemon no longer prints the daemon token in its "do this next" box;
  the command it shows reads the token from .env.
• Runner: a failed upload, publish, fetch or topic says what happened. Failures of the runner's own
  disk or database on these routes answer with one sentence (which step failed; permission
  denied, disk full, read-only or missing; what to do) and an error_id that is also in the
  runner's log line, instead of "storage error" or "query failed". A full disk during an upload is
  reported as one, not as "upload interrupted". An attachment whose bytes are gone answers 410
  to the agent, as it already did to a person. The remaining fragment replies on these routes
  ("session has ended", "file no longer available", "no database", "invalid JSON body") are
  sentences now.
• Messaging CLI (blerg-runner): requests to a local server or board (localhost, a loopback
  address, a one-word name such as blerg-runner) no longer go through a proxy from the
  environment, so a corporate proxy that Docker injects into a session container cannot swallow
  them; other addresses still honour the proxy. Every request goes through one helper, and a
  failure of publish, fetch, topic and the rest says the HTTP status, the server's sentence
  and error id (or an older server's raw reply, trimmed), the address called (without any
  user:password), and for a con...