v0.2.0-alpha.8

BuildMax is an out-of-the-box, privately deployable Agent platform: a CLI/TUI,
a desktop app, and a space Portal on one shared Go Agent Runtime.

Install

Download the archive for your platform below. Each one contains all three
binaries — buildmax, buildmax-server, buildmax-worker — plus
config-examples/, LICENSE, and NOTICE-THIRD-PARTY. Verify it against
checksums.txt first.

With a Go toolchain, for the CLI alone:

go install github.com/gougoujiang/buildmax/cmd/buildmax@v0.2.0-alpha.8

As a container, for linux/amd64 and linux/arm64:

docker pull ghcr.io/gougoujiang/buildmax:0.2.0-alpha.8

Copy config-examples/settings.example.yaml to ~/.buildmax/settings.yaml,
configure at least one model, then run buildmax for the TUI or
buildmax -p "your prompt" for a single non-interactive turn. Running the
server and Portal additionally needs MySQL and object storage; see the README.

The desktop app is not published here. It needs code signing and notarization
to launch on macOS, so build it locally with ./make build.

Before you deploy this

This is an alpha, and two defaults deserve to be read as warnings rather than
footnotes:

• Server authentication is bootstrap-level. There is no mail channel, so an
  operator creates accounts and issues single-use login codes with
  buildmax-server user create and user login-code. Self-registration is
  closed by default. There is no password, second factor, SSO, or recovery
  flow; putting the Portal on a network you do not control requires wiring a
  real identity provider first.
• The bash sandbox is off by default, and worker hardening is incomplete.

SECURITY.md lists both, along with how to report a vulnerability privately.
Interfaces and deployment guidance may change before a stable release.

Added

• The Portal agent dialog now has a Plugins group for choosing which catalog
  plugins an agent loads on its background runs, offering only the plugins the
  space can name and keeping any already-named plugin visible even if it is no
  longer available.

• The Portal artifact page now renders Markdown artifacts as formatted text and
  shows HTML artifacts as a live page in a sandboxed frame, instead of offering
  only a download for them.

• Artifacts can now be given a revocable public link that opens without a
  BuildMax login and renders in the Portal (Markdown formatted, HTML in a
  sandbox); UploadArtifact(share=true) returns one, and the server builds it
  from the new public_base_url / BUILDMAX_PUBLIC_BASE_URL setting.

• Desktop's file browser and changes panel now syntax-highlight file and diff
  content, the file browser adds a Source/Preview toggle for Markdown files,
  and the changes panel adds a List/Tree toggle that groups changed files by
  directory.

• Desktop now has a docked inspector column on the right for browsing workspace
  files, reviewing changes, and reading session info, replacing the slide-over
  drawers: switch views from the header, drag to resize it, expand it to fill
  the chat area for review, and collapse the left sidebar to give the
  conversation the full width.

• Add ./make e2e desktop-ui, which drives desktop/frontend's React app and
  its bound Go methods through wails dev's browser dev server against a
  fresh, discarded BUILDMAX_HOME; ./make run desktop-dev starts that same
  dev server for ad hoc use, and .buildmax/skills/drive-desktop/ is a
  Playwright REPL for poking at it by hand.

• ./make kind fixtures seeds a running local Kubernetes deployment with an
  idempotent set of business data — two accounts with personal spaces, an agent,
  a workflow, and issues across every status — so automated Portal testing can
  start from populated views instead of an empty deployment.

• A running deployment can now flip its own conversations and task runs
  between a seeded catalog model and the free mock by environment alone —
  BUILDMAX_WORKER_LLM_TRANSPORT, BUILDMAX_LLM_DEFAULT_MODEL, and
  BUILDMAX_CONVERSATION_MODEL_TARGET override the matching server.yaml
  fields, conversation.model_target accepts a model name as well as an ID, and
  ./make kind use-model <name> / ./make kind mock switch a kind cluster.

• Portal agents can now choose which model their background runs call, so
  different agents can run on different models. The agent editor offers the
  deployment's catalog models plus a "Deployment default"; an unknown model is
  refused on save, and the choice takes effect on the managed worker transport.

• Portal now has a global Marketplace page, reached from a storefront button in
  the header beside the theme toggle, that lists the plugins this deployment
  publishes and how to install them.

• Space owners and admins can set shared Agent instructions that every
  background run inherits before its selected Agent's own instructions.

• The local kind deployment now runs the worker control channel over HTTPS with
  a generated certificate, and ./make kind verifies the worker API boundary in
  the same smoke: a labelled worker pod reaches the internal listener, an
  unlabelled pod is denied it by the NetworkPolicy, and /api/worker answers
  404 on the public Service.

• The reference Kubernetes manifests now separate the worker control API from
  the public API: a buildmax-api Service behind the Ingress, an internal
  buildmax-worker-api ClusterIP on port 5679, a NetworkPolicy that admits
  only labelled worker pods to that port, and the worker-api CA mounted
  read-only into each worker Job.

• The /worktree panel now marks each tree as clean or with its uncommitted and
  unmerged counts, and can remove a stale one in place with d — a confirm that
  names what would be discarded before a tree holding work is deleted.

Changed

• The agent Configuration tab now uses a left sidebar of sections (Basics,
  Sandbox access, Plugins, Secrets) showing one section at a time, instead of a
  tall stack of cards, so every configuration group is visible at a glance.

• The Portal create agent dialog now organises configuration into tabs down a
  left sidebar (Basics, Sandbox access, Plugins, Secrets), so the dialog's
  height stays bounded instead of growing into one long scroll.

• The Portal Agents section now opens each agent on its own page — Overview,
  Configuration, Runs (execution history), and Revisions — instead of an edit
  dialog, and the Agents home adds an overview with space-wide run counts, a
  success rate, and a recent-activity feed across agents.

• The chat composer's Send and Stop buttons are now compact icons, in both
  Desktop and Portal; the action's word stays as the button's accessible label.

• Desktop shows context-window usage as a donut gauge after the git branch in
  the status bar, filling amber then red as the window fills; clicking it opens
  the exact used, free, and window token counts.

• Desktop now triggers panels through TUI-style slash commands typed in the
  chat input — /info, /diff, /mcp, /tools, /worktree, /compact, and
  the rest — replacing the row of buttons below the composer. /agents and
  /plugins are now slash commands in the terminal UI too.

• Portal no longer shows internal entity IDs on the artifacts list, artifact
  detail, and agent detail pages, leaving only the information a user acts on.

• ./make kind reload replaces ./make kind images: it still builds and loads
  the local images, and now also restarts the buildmax-server and
  buildmax-portal deployments so a code change takes effect without a full
  ./make kind up.

• The local kind stack now generates an ephemeral Space Secret key-encryption
  key and mounts it, so the Secrets feature can be exercised end to end there
  instead of answering "secrets not configured"; the deployment baseline mounts
  the key from an optional Secret so other deployments are unaffected.

• The ownership and authorization boundary is renamed from Team to
  Space across the product: API routes move from /api/teams/{team_id}
  to /api/spaces/{space_id}, the team_id JSON field becomes space_id,
  and Portal, the CLI, and stored data use Space throughout. This is a
  breaking API change with no compatibility shim, as the Alpha allows.

• A Space's Secrets page was redesigned into per-secret cards with an
  at-a-glance state, item-name chips, a clearer create form, and a security
  caution restyled from an alarm into a readable note.

• A Space's sandbox defaults moved out of the Plugins tab into their own
  Security tab, and the Plugins tab was redesigned into scannable per-plugin
  cards with an at-a-glance activation status.

• The Task page now streams the in-flight run's output live over server-sent
  events instead of only polling: tokens appear as the agent produces them,
  and the poll continues to own run lifecycle and status so a dropped or
  draining stream falls back cleanly.

• The Portal task page leads with the conversation; a Details button in the
  header (beside Open agent) opens a dialog with the task's agent, timing,
  origin, and trace/files entry points, instead of foregrounding backend run
  numbers, repeating controls under every message, or crowding the transcript.

• While an agent run is in flight, the Portal task conversation now shows an
  animated working indicator instead of the raw "Run pending / scheduled /
  running" status text, which the reader does not need to see.

• Trim the status footer to just the context share on both the CLI TUI and the
  Desktop status bar; the CLI's per-run token and cache breakdowns stay
  available under /info.

• The worker control API (/api/worker/*) is now served on a separate internal
  listener, off the public HTTP surface. It binds 127.0.0.1:5679 by default,
  so set worker.server_url to that listener (via worker_api.listen) rather
  than the public port; the public listener answers 404 for worker routes.

##...

v0.2.0-alpha.7

BuildMax is an out-of-the-box, privately deployable Agent platform: a CLI/TUI,
a desktop app, and a team Portal on one shared Go Agent Runtime.

Install

Download the archive for your platform below. Each one contains all three
binaries — buildmax, buildmax-server, buildmax-worker — plus
config-examples/, LICENSE, and NOTICE-THIRD-PARTY. Verify it against
checksums.txt first.

With a Go toolchain, for the CLI alone:

go install github.com/gougoujiang/buildmax/cmd/buildmax@v0.2.0-alpha.7

As a container, for linux/amd64 and linux/arm64:

docker pull ghcr.io/gougoujiang/buildmax:0.2.0-alpha.7

Copy config-examples/settings.example.yaml to ~/.buildmax/settings.yaml,
configure at least one model, then run buildmax for the TUI or
buildmax -p "your prompt" for a single non-interactive turn. Running the
server and Portal additionally needs MySQL and object storage; see the README.

The desktop app is not published here. It needs code signing and notarization
to launch on macOS, so build it locally with ./make build.

Before you deploy this

This is an alpha, and two defaults deserve to be read as warnings rather than
footnotes:

• Server authentication is bootstrap-level. There is no mail channel, so an
  operator creates accounts and issues single-use login codes with
  buildmax-server user create and user login-code. Self-registration is
  closed by default. There is no password, second factor, SSO, or recovery
  flow; putting the Portal on a network you do not control requires wiring a
  real identity provider first.
• The bash sandbox is off by default, and worker hardening is incomplete.

SECURITY.md lists both, along with how to report a vulnerability privately.
Interfaces and deployment guidance may change before a stable release.

Added

• Portal's agent editor can now set an agent's network and filesystem
  sandbox tier directly, and a team can set the default tier an agent
  inherits when it declares neither, from a new "Sandbox defaults" section
  on the team's Plugins settings tab.

• A background agent definition can now declare a network sandbox tier
  (none/registries/open) and a filesystem tier (workspace/shared-read/
  external-write) that its worker runs apply, without an operator
  hand-editing policy.yaml per agent.

• Deleted and expired artifacts now have their stored objects reclaimed by an
  hourly retention sweep, so deleting an artifact eventually frees the bytes
  instead of only hiding it; storage.artifact_purge_after_days delays that,
  and the sweep records what it expired and reclaimed in the audit trail.

• ./make test mysql runs the store tests against a real MySQL on a database
  it creates and drops, and every pull request now runs it against a pinned
  server. The tests existed but skipped themselves without a DSN, so schema,
  query, and transaction behavior was outside ordinary change review.

• Artifacts are now a top-level area in Portal instead of a space-settings
  tab, and each one has its own page at #/artifact/<id> showing its
  provenance, size, digest, and preview — so an ar_ reference an agent
  returns is something a teammate can open, not just look up in a list.

• A run whose sandbox resolved weaker than its surface's own baseline — or
  fell back to unconfined because the OS backend was unavailable — now logs a
  warning at startup and marks the run's trace and SessionStart hook
  payload as downgraded, instead of proceeding silently.

• The sandbox can now bound a Bash command's own CPU time, memory, process
  count, and open file descriptors (sandbox.process.* in settings.yaml /
  policy.yaml). Memory limits have no effect on macOS, which does not
  support them at the OS level.

• The CLI's /skills panel is now selectable: arrow keys move, typing filters
  by name or description, and Enter fills the input with /<skill-name> for
  you to finish and send, matching Desktop's skill picker.

• The store's four conditional-update claims — task claiming, run transition,
  result-delivery claiming, and cancellation beside a worker's report — are now
  tested against a real MySQL under contention, so a run cannot quietly be
  claimed twice or a task summary delivered twice.

• A quota tier can now cap what a space's artifacts hold in total with
  max_storage_bytes, refusing an upload that would cross it; space settings
  report storage alongside runs and tokens. The seeded tiers set no limit, so
  an existing deployment is unaffected until an operator chooses one.

• The deployment smoke now dispatches a real task that calls the Bash tool
  through the worker and checks the sandbox actually confined it, so a
  regression in worker sandboxing is caught automatically instead of only by
  manual reproduction.

Changed

• ./make e2e local now picks a fresh Compose project name and ports for
  every run instead of a fixed one, so it never collides with a contributor's
  persistent stack or another concurrent run. ./make compose up/kind up
  can also be pointed at a second, differently named and ported stack with
  BUILDMAX_COMPOSE_PROJECT/BUILDMAX_KIND_CLUSTER and matching port
  variables, so multiple deployments can run side by side.

• ./make e2e now requires a suite instead of defaulting to kind. The default
  was the suite with the heaviest prerequisite, so a bare invocation reported a
  missing cluster rather than a missing argument; it now prints the six suites
  and what each one needs.

• Local kind manifests now live under deployment/kind/, dropping the old
  dev- directory prefix; the ./make kind command surface is unchanged.

• Contributor-local configuration now lives in one gitignored .local/
  directory, created by ./make setup local from the committed templates. The
  repository-root .env became .local/env, settings.local.yaml became
  .local/settings.yaml, and the local copy of
  deployment/buildmax-secret.example.yaml became .local/buildmax-secret.yaml.
  ./make doctor reports whether the directory is there, and the command moves
  files left at the old paths rather than duplicating them.
  deployment/compose/.env is unchanged: Compose reads it from the compose
  file's own directory.

• ./make help now groups commands by what running one does — the everyday
  local ones, the model runs that need an API key, the deployments that start
  containers or bill a provider, and the release chores — replacing an
  "Advanced" section that held fmt next to the DigitalOcean infrastructure.

• Trimmed the long-winded comments in config-examples/*.example.yaml down
  to the facts a reader needs, keeping every documented key and default.

• Adding a team member is now an invitation: POST /api/teams/{team_id}/members
  is replaced by POST /api/teams/{team_id}/invitations, which creates a
  pending offer instead of adding the account immediately. The invited
  account sees it at GET /api/invitations and confirms it at
  POST /api/invitations/{invitation_id}/accept. Inviting an email with no
  BuildMax account is refused, naming the system_admin path to create one
  first — team-scoped invitation never creates an account. Admin may now
  invite at the member role; owner may invite at member or admin. A team
  owner can also PATCH /api/teams/{team_id}/members/{user_id} to promote or
  demote a member without a remove/re-add round trip, transfer ownership by
  setting a target's role to owner (unilateral and immediate), and
  POST /api/teams/{team_id}/members/{user_id}/login-code to recover a
  locked-out member of their own team without needing a system_admin.
  Portal's Space → Members page has an Invite dialog, a pending-invitations
  list with revoke, a role selector, a distinct ownership-transfer
  confirmation, and a login-code action; Account → Invitations lists and
  accepts what has been sent to the signed-in user.

Fixed

• Creating a conversation now rejects a channel the caller may not claim.
  workflow, issue_agent, and system mark a conversation the server made
  and nobody holds; naming one produced a conversation the Portal rendered as
  agent-owned and the list hid. Only portal, telegram, cron, and
  webhook are accepted, and an unknown channel is a 400 rather than a stored
  string nothing understands.

• ./make kind seed reads a model's cache_control and pricing blocks and
  passes them to the catalog, so a seeded deployment answers with the same
  cache policy and rates as the local settings it was seeded from. It no longer
  reads the removed prompt_cache key, whose flag the catalog command dropped —
  a settings file that still carried it failed the whole seed.

• A quota limit that cannot be read now refuses the work instead of admitting
  it. A failed team, tier, or usage lookup was reported as "allowed", so a
  deployment whose database was unreachable served unmetered runs and managed
  inference and recorded nothing about having done so. Such a failure is a 500
  naming the read that failed, distinct from the 429 an over-quota team gets;
  a team with no record, no tier, or a tier that names nothing is still
  admitted, because absence of a limit is not the same as not knowing. Team
  usage reports the same way rather than showing a zeroed snapshot.

• Creating a team now reports its plugin curation mode as open rather than
  leaving the field empty, so the team returned by a create and the same team
  returned by a later read no longer disagree about who fills its plugin
  activation list.

• Worker pods now use a custom seccomp profile instead of Kubernetes'
  RuntimeDefault, and the sandbox re-binds /proc instead of mounting a
  fresh one — both were silently preventing the worker's Bash sandbox from
  running at all once deployed to a real cluster.

Security

• command and http hooks now run through the same sandbox confinement
  that already applies to `Bash...

v0.2.0-alpha.6

BuildMax is an out-of-the-box, privately deployable Agent platform: a CLI/TUI,
a desktop app, and a team Portal on one shared Go Agent Runtime.

0.2.0-alpha.5 carries the same changes but published nothing: it was tagged,
and its release build then failed before uploading any archive or image. Only
its Portal image exists. This version replaces it.

Highlights

• The agent now remembers a local project between sessions. Each project keeps
  small Markdown memories under a generated index; only the index is carried
  into a turn, and the agent opens a memory when the line suggests it is worth
  reading. Every surface can see what a project remembers: buildmax info, the
  TUI /info panel, and a read-only Memory view in Desktop.
• Team issues reach the terminal. buildmax issue list, issue show, and
  issue status work the issues a team assigned you, and buildmax --issue <id> scopes a local session to one: the agent reads the issue and reports
  back, while status, assignee, and sub-issues stay a person's decision.
• Desktop and the CLI share one local project catalog, so both list the same
  sessions for the same repository, worktrees included.
• /compact compacts a TUI session on demand instead of waiting for the
  context window to fill.
• Alpha releases prepare themselves: a daily check opens a reviewable pull
  request, and merging it is what creates the tag.

Upgrade notes

• A deployment running workers as Kubernetes Jobs must set all four
  worker.k8s.resources bounds. The server now refuses to start when one is
  missing or invalid, naming the key to edit, instead of logging the problem
  and running worker pods unbounded.
• buildmax stats is now buildmax info, and the TUI /stats panel is
  /info. Scripts reading --json get the statistics under stats and the
  new memory listing under project_memory.
• A run trace's prompt_layers record is now context_sources. Anything
  reading traces has to follow the rename; the record now names every source a
  run started with, not only the system-prompt layers.
• --continue is now scoped to the directory you are in, not the newest
  session anywhere on the machine. --continue --project widens it to every
  directory of the project and prints where it will run.

Install

Download the archive for your platform below. Each one contains all three
binaries — buildmax, buildmax-server, buildmax-worker — plus
config-examples/, LICENSE, and NOTICE-THIRD-PARTY. Verify it against
checksums.txt first.

With a Go toolchain, for the CLI alone:

go install github.com/gougoujiang/buildmax/cmd/buildmax@v0.2.0-alpha.6

As a container, for linux/amd64 and linux/arm64:

docker pull ghcr.io/gougoujiang/buildmax:0.2.0-alpha.6

Copy config-examples/settings.example.yaml to ~/.buildmax/settings.yaml,
configure at least one model, then run buildmax for the TUI or
buildmax -p "your prompt" for a single non-interactive turn. Running the
server and Portal additionally needs MySQL and object storage; see the README.

The desktop app is not published here. It needs code signing and notarization
to launch on macOS, so build it locally with ./make build.

Before you deploy this

This is an alpha, and two defaults deserve to be read as warnings rather than
footnotes:

• Server authentication is bootstrap-level. There is no mail channel, so an
  operator creates accounts and issues single-use login codes with
  buildmax-server user create and user login-code. Self-registration is
  closed by default. There is no password, second factor, SSO, or recovery
  flow; putting the Portal on a network you do not control requires wiring a
  real identity provider first.
• The bash sandbox is off by default, and worker hardening is incomplete.

SECURITY.md lists both, along with how to report a vulnerability privately.
Interfaces and deployment guidance may change before a stable release.

Added

• The agent can now remember things about a local project between sessions. A
  project keeps one bounded memory store at
  <BUILDMAX_HOME>/projects/<project_id>/memory/: small Markdown files, one
  per memory, under a generated MEMORY.md index. Only the index is shown to
  the model on every turn, as fallible recall rather than as instruction --
  AGENTS.md stays the place for rules -- and the agent opens a memory's body
  with MemoryRead when the line suggests it is worth reading. MemoryWrite
  creates, replaces, or deletes one memory at a time, and changing a memory
  requires having read it, so two sessions recording different facts never
  collide and a stale write risks one memory instead of the store. Subagents
  receive neither the index nor the tools. The store is shared by every session
  of that project, including those in other worktrees of the same repository,
  it is yours to read, edit, or empty at any time, and --no-project-memory
  runs without it in either direction.

• buildmax --issue <id> scopes a local session to a team issue: the agent can
  read the issue, its sub-issues, and recent discussion, and post a short report
  back. It cannot change the issue's status, assignee, or sub-issues. A report
  from your machine is recorded as a local agent report attributed to you, and
  Portal shows it as reported rather than said — it is not a run the deployment
  scheduled, counted, or traced.

• buildmax issue list shows the issues a team assigned you, across every team
  you belong to, so team work can be picked up from the terminal instead of a
  board in a browser. Listing issues by assignee and by status now works over
  the API too; both filters were described but not implemented.

• buildmax issue show <id> prints one issue with its sub-issues and recent
  discussion, and buildmax issue status <id> <status> moves it when you are
  done. Moving status stays a person's action: an agent working the issue can
  say it believes the work is finished, and you decide. A session started with
  --issue now also prints which server, team, and issue it is working and
  where prompts go, before the first model call.

• An agent working a team issue can now read it and report back. GetIssue
  returns the issue, its sub-issues, and recent discussion; ReportToIssue
  posts one bounded comment on the thread. Both are scoped to the issue the run
  was started for, and neither can change its status, assignee, or sub-issues.

• /compact in the TUI summarizes the conversation so far and continues from
  the summary, instead of waiting for the context window to fill up. It keeps a
  much shorter tail verbatim than the automatic pass, reports what it replaced
  and what the context costs now, and honors the same pre_compact and
  post_compact hooks.

• Desktop has a Memory button beside the message box: it lists what the
  project remembers and shows the body of whichever memory you select, over the
  same store the CLI and TUI read. It is read-only for now — memories are
  Markdown files and the drawer prints the directory so you can edit them
  directly — and it names any file that could not be parsed, since such a memory
  is silently absent from every run until it is repaired.

• buildmax project list shows the local projects and marks the ones whose
  locator no longer resolves; buildmax project relink <project-id> points one
  at the current directory after a repository or folder has moved, keeping the
  memories and sessions attached to it. A run that registers a new project while
  others are unresolved now says so and names the command, since otherwise the
  duplicate looks like the feature working.

• A daily release check now prepares a reviewable pull request once the latest
  alpha is at least 72 hours old and user-visible changes are waiting. Merging
  that pull request creates the version tag and starts the existing publication
  workflows; an empty or unreviewed release is never published on the timer.

• Add ./make ocean to provision disposable DigitalOcean infrastructure, deploy a pinned private application trial, inspect it, and tear it down for beta qualification.

• Add idempotent OpenRouter model initialization for the DigitalOcean trial,
  including automatic selection and rollout of the Tier 1 conversation model.

• Add ./make ocean show all to inspect the standard Kubernetes workload
  resources in the BuildMax namespace with the qualification cluster's isolated
  kubeconfig.

• Add an owner-only Kubernetes tunnel for inspecting the qualification MySQL
  database locally without opening its firewall to the public internet.

Changed

• A deployment running workers as Kubernetes Jobs must now set all four
  worker.k8s.resources bounds, and the server refuses to start when one is
  missing, is not a Kubernetes quantity, is zero or negative, or names a limit
  below its own request. The error names the key to edit. Previously a typo such
  as memory_limit: 4 gigabytes was logged and dropped, which left worker pods
  running model-chosen commands with no memory limit while the configuration
  looked correct.

• --continue now resumes the newest session recorded in the directory you are
  in, rather than the newest session anywhere on the machine. In a repository
  with worktrees, a project-wide search could pick a session from a sibling
  worktree and run there, moving your working root out from under the workflow
  whose whole purpose is branch isolation. When this directory has no sessions
  but the project does, --continue says how many and names --continue --project, which widens the search and prints the directory it will run in.
  The TUI /sessions picker spans the project -- one Git repository including
  all its worktrees, or one plain folder -- and marks sessions recorded in
  another tree; press a to see every project. --resume <id> still finds a
  session by id, but returns to the directory it ra...

v0.2.0-alpha.4

BuildMax is an out-of-the-box, privately deployable Agent platform: a CLI/TUI,
a desktop app, and a team Portal on one shared Go Agent Runtime.

Highlights

• A container-image-only security fix. Both published images apply their base
  image's pending security updates at build time, so they no longer ship an
  openssl the alpine branch has already patched. Nothing else changed since
  0.2.0-alpha.3.

Upgrade notes

• Operators running the 0.2.0-alpha.3 images should pull this version.
  ghcr.io/gougoujiang/buildmax:0.2.0-alpha.3 and
  ghcr.io/gougoujiang/buildmax-portal:0.2.0-alpha.3 carry CVE-2026-14456 in
  openssl 3.5.7-r0; their base tags lagged the fix alpine had published as
  3.5.8-r0. The archives are unaffected — the binaries are built with
  CGO_ENABLED=0 and do not link the system openssl — so an installation from
  a 0.2.0-alpha.3 archive needs nothing.

Install

Download the archive for your platform below. Each one contains all three
binaries — buildmax, buildmax-server, buildmax-worker — plus
config-examples/, LICENSE, and NOTICE-THIRD-PARTY. Verify it against
checksums.txt first.

With a Go toolchain, for the CLI alone:

go install github.com/gougoujiang/buildmax/cmd/buildmax@v0.2.0-alpha.4

As a container, for linux/amd64 and linux/arm64:

docker pull ghcr.io/gougoujiang/buildmax:0.2.0-alpha.4

Copy config-examples/settings.example.yaml to ~/.buildmax/settings.yaml,
configure at least one model, then run buildmax for the TUI or
buildmax -p "your prompt" for a single non-interactive turn. Running the
server and Portal additionally needs MySQL and object storage; see the README.

The desktop app is not published here. It needs code signing and notarization
to launch on macOS, so build it locally with ./make build.

Before you deploy this

This is an alpha, and two defaults deserve to be read as warnings rather than
footnotes:

• Server authentication is bootstrap-level. There is no mail channel, so an
  operator creates accounts and issues single-use login codes with
  buildmax-server user create and user login-code. Self-registration is
  closed by default. There is no password, second factor, SSO, or recovery
  flow; putting the Portal on a network you do not control requires wiring a
  real identity provider first.
• The bash sandbox is off by default, and worker hardening is incomplete.

SECURITY.md lists both, along with how to report a vulnerability privately.
Interfaces and deployment guidance may change before a stable release.

Security

• The published container images now apply their base image's pending security
  updates at build time. A base tag lags its branch's updates, so
  ghcr.io/gougoujiang/buildmax:0.2.0-alpha.3 and the matching
  buildmax-portal image shipped openssl 3.5.7-r0 while alpine had already
  published 3.5.8-r0, and the release scan failed on CVE-2026-14456 after both
  images were pushed. The binaries in the archives were never affected: they
  are built with CGO_ENABLED=0 and do not link the system openssl.

---

Earlier releases are in
CHANGELOG.md.

v0.2.0-alpha.3

BuildMax is an out-of-the-box, privately deployable Agent platform: a CLI/TUI,
a desktop app, and a team Portal on one shared Go Agent Runtime.

Highlights

• Ask the TUI agent for a worktree and it makes one, moves the session into it,
  and works there — every tool follows, along with the tree's own hooks,
  skills, and MCP servers. /worktree shows what exists and who is in it, and
  a delegated subagent can be given a worktree of its own.
• BuildMax can be measured on Terminal-Bench. evaluation/harbor/ pins the
  harness, the dataset, and the adapter that runs the built CLI inside a task
  container, and ./make eval harbor run starts a run and files it as trial
  bundles in the same contract as the local suite. Harbor stays the harness and
  its verifier stays authoritative.
• A Bash command that leaves a background process behind no longer hangs the
  agent. The tool waited on a pipe the process inherited, so a run was observed
  sitting on one call for two hours under a documented 120-second budget.
• A task run whose worker is killed without warning now fails within minutes.
  The server records the poll a worker already makes, and the reaper closes a
  run that has gone quiet — instead of leaving the Portal showing work in
  progress until the six-hour timeout.
• The agent loop's iteration cap is configurable with agent.max_iterations
  and --max-iterations, so a long unattended task is not cut off at the fixed
  200 that suited interactive work.
• A run that fails part way through reports what it did before it failed. The
  workspace, model, elapsed time, tool calls, and tokens already spent were all
  dropped on the failure path, in text and in --output json alike.

Upgrade notes

• A run that reaches the iteration cap now exits 7, with error kind
  iteration_cap, rather than sharing 4 with a failed model call. A script or
  harness that read 4 as a spent budget should follow the new code; 4 now
  means a fault worth retrying.
• /rewind takes a prompt back rather than moving to a message: it removes the
  prompt you pick along with everything after it and returns its text to the
  input box to edit and send again. Neither /rewind nor /fork offers an
  assistant message that asked for a tool any more, because choosing one left
  the conversation holding a tool call with no result.
• ./make eval now measures CLI tasks only. Pass --surface worker for the
  worker tasks, or --surface all for both, which is what it used to run.
• A worker that finds its run already claimed exits 0 instead of 2. Nothing
  read the code, and under Kubernetes the non-zero exit restarted a pod that
  could only refuse the run again.

Install

Download the archive for your platform below. Each one contains all three
binaries — buildmax, buildmax-server, buildmax-worker — plus
config-examples/, LICENSE, and NOTICE-THIRD-PARTY. Verify it against
checksums.txt first.

With a Go toolchain, for the CLI alone:

go install github.com/gougoujiang/buildmax/cmd/buildmax@v0.2.0-alpha.3

As a container, for linux/amd64 and linux/arm64:

docker pull ghcr.io/gougoujiang/buildmax:0.2.0-alpha.3

Copy config-examples/settings.example.yaml to ~/.buildmax/settings.yaml,
configure at least one model, then run buildmax for the TUI or
buildmax -p "your prompt" for a single non-interactive turn. Running the
server and Portal additionally needs MySQL and object storage; see the README.

The desktop app is not published here. It needs code signing and notarization
to launch on macOS, so build it locally with ./make build.

Before you deploy this

This is an alpha, and two defaults deserve to be read as warnings rather than
footnotes:

• Server authentication is bootstrap-level. There is no mail channel, so an
  operator creates accounts and issues single-use login codes with
  buildmax-server user create and user login-code. Self-registration is
  closed by default. There is no password, second factor, SSO, or recovery
  flow; putting the Portal on a network you do not control requires wiring a
  real identity provider first.
• The bash sandbox is off by default, and worker hardening is incomplete.

SECURITY.md lists both, along with how to report a vulnerability privately.
Interfaces and deployment guidance may change before a stable release.

Added

• Ask the TUI agent for a worktree and it makes one, moves the session into it,
  and works there — every tool follows, along with the tree's own hooks,
  skills, and MCP servers. /worktree shows what exists and who is in it;
  removal asks first and refuses to discard uncommitted work. A delegated
  subagent can be given a worktree of its own with Task's worktree
  argument.

• ./make build cli <os/arch> cross-builds a static CLI for another platform
  and names the artifact buildmax-<os>-<arch>, leaving the host binary in
  place. It is how the CLI gets into a container image the project does not
  own, such as an external benchmark's.

• ./make build desktop packages the Wails desktop app on its own, without
  spending the server, worker, and Portal builds to get at it. CI now runs it
  on macOS and Windows after a merge that touches the app, weekly, and on
  demand: nothing built the packaged app before, so a break in the asset
  embedding, the Wails configuration, or the native link waited for whoever ran
  ./make build next.

• Add ./make eval harbor run, which starts a Terminal-Bench run rather than
  only importing one. It assembles the Harbor command from
  evaluation/harbor/pins.json — dataset ref, adapter import path, and the
  PYTHONPATH that lets Harbor import the adapter — checks the toolchain the
  way ./make doctor harbor does, cross-builds the linux/amd64 CLI if it is
  missing, and imports the finished job. Tasks are selected with --task,
  --canary, --limit, or --all, and there is no default: the default would
  be all 89. --oracle runs each task's own reference solution to prove the
  environment, and --dry-run prints the command without running it. Harbor
  still owns the tasks, the containers, and the verdict.

• Add evaluation/harbor/: pinned Harbor, dataset, and adapter versions, the
  custom-Agent adapter that runs the built CLI against Terminal-Bench 2.1 inside
  a task container, and ./make eval harbor --job <dir>, which files a finished
  job as BuildMax trial bundles and reports it in the same contract as the local
  suite — same subject tuple, same failure taxonomy, same pass rate with its
  uncertainty. Harbor stays the harness and its verifier stays authoritative:
  BuildMax neither re-runs the benchmark nor re-grades it, and an agent timeout,
  a verifier timeout, and a container that never started stay three different
  facts. ./make doctor harbor reports what a run needs, reading the pinned
  versions rather than restating them, and prints the fix for each missing piece
  instead of installing anything.

• Make the agent loop's iteration cap configurable with agent.max_iterations
  in settings.yaml and --max-iterations for one run, so a long unattended
  task is not cut off at the fixed 200 that suited interactive work. A run that
  reaches the cap now exits 7 with error kind iteration_cap rather than
  sharing 4 with a failed model call, so a script or harness can tell a spent
  budget from a fault worth retrying.

• Add fail-closed --sandbox and --sandbox-mode controls for requiring Bash
  confinement on one CLI run without changing settings or weakening policy.

• BUILDMAX_SERVER_URL can now select the BuildMax server offered at CLI and
  Desktop sign-in and used by workers without rewriting configuration files.

• Add ./make setup harbor, the write half of ./make doctor harbor: it
  installs uv when it is missing, installs the Harbor version pinned by
  evaluation/harbor/pins.json, cross-builds the linux/amd64 CLI a trial
  uploads, and finishes by re-running doctor's own probes, so what setup
  installs and what a benchmark run requires cannot drift apart. Steps already
  done are skipped. Installing uv runs Astral's installer, and the exact command
  is printed before it runs. A trial sandbox stays yours to choose: setup reports
  that Docker or a DAYTONA_API_KEY is missing rather than picking one. Doctor
  still installs nothing. Both commands now name linux/amd64 rather than the
  host's architecture, because the architecture that matters is the task image's:
  an arm64 binary uploaded into an emulated image fails with an exec format error
  once the trial is already running.

• Hooks can subscribe to worktree_create, worktree_remove, and
  cwd_changed, so an audit or notification hook can follow which tree a
  session is working in. All three are advisory.

Changed

• ./make eval now runs only CLI evaluation tasks by default; select worker
  tasks with --surface worker or both surfaces with --surface all.

• /rewind now takes a prompt back rather than moving to a message: it lists
  the prompts you typed, removes the one you pick along with everything after
  it, and returns its text to the input box to edit and send again. The Desktop
  History panel does the same, and lists rewind and fork points separately.

Fixed

• Stop a Bash command that leaves a background process behind from hanging the
  agent forever. The tool reads output through a pipe, and a server or daemon
  the command started inherits the write end and holds it open, so the wait
  outlived both the command and its timeout — a run was observed sitting on one
  call for two hours under a documented 120-second budget. The tool now stops
  waiting shortly after the command ends or its deadline passes, and says so
  when output was cut short.

• Report what an evaluation run spent. The trial home a trial runs under carried
  a model entry with no prices, so ./make eval had always reported cost ...

v0.2.0-alpha.2

BuildMax is an out-of-the-box, privately deployable Agent platform: a CLI/TUI,
a desktop app, and a team Portal on one shared Go Agent Runtime.

Highlights

• A conversation can go back: /rewind in the TUI moves it to an earlier
  message, /fork branches a new session off one, and Desktop offers both
  behind a History button. Each names the tools that ran in the span you
  are choosing across, because rewinding moves the conversation and does not
  undo the files those tools wrote.
• A session is now a folder — metadata, an append-only conversation journal,
  and its own run traces — written as the turn happens rather than rewritten
  after it. An interrupted run keeps everything up to the moment it stopped,
  and a session can only be open in one place at a time.
• Logins are kept in the operating system's credential store (Keychain,
  Credential Manager, Secret Service) instead of as plaintext in auth.json.
• A turn ends with a dim recap of what it did, and the answer you are likely
  about to type is offered as ghost text when the agent asks you something.
• openapi.json now describes every route the server registers — 117
  operations instead of 40 — held to an exact match by a test in both
  directions.

Upgrade notes

• Sessions from earlier versions are ignored. The move to sessions/<id>/
  ships with no conversion, and the traces/ root is gone with it. Existing
  conversations and their traces stay on disk untouched; BuildMax will not
  read them. Delete them, or keep them for reference.
• A plaintext auth.json is moved into the credential store the first time it
  is read, so a login survives the upgrade. A machine with no usable store
  falls back to the file as before, and BUILDMAX_CREDENTIAL_STORE=file keeps
  the previous behavior deliberately. buildmax login, whoami, and doctor
  say which one a login is actually using.
• API clients generated from openapi.json will see far more than the routes
  change: created_at, started_at, and ended_at are typed as RFC 3339
  strings rather than integers, which is what the API has always sent, and
  managed inference is documented at /api/llm/models and
  /api/llm/completions rather than the team-scoped paths that never existed.
• A Compose stack that moves the Portal off 8080 should set
  BUILDMAX_CORS_ORIGIN, which now follows BUILDMAX_PORTAL_PORT, instead of
  hand-editing server.yaml.

Install

Download the archive for your platform below. Each one contains all three
binaries — buildmax, buildmax-server, buildmax-worker — plus
config-examples/, LICENSE, and NOTICE-THIRD-PARTY. Verify it against
checksums.txt first.

With a Go toolchain, for the CLI alone:

go install github.com/gougoujiang/buildmax/cmd/buildmax@v0.2.0-alpha.2

As a container, for linux/amd64 and linux/arm64:

docker pull ghcr.io/gougoujiang/buildmax:0.2.0-alpha.2

Copy config-examples/settings.example.yaml to ~/.buildmax/settings.yaml,
configure at least one model, then run buildmax for the TUI or
buildmax -p "your prompt" for a single non-interactive turn. Running the
server and Portal additionally needs MySQL and object storage; see the README.

The desktop app is not published here. It needs code signing and notarization
to launch on macOS, so build it locally with ./make build.

Before you deploy this

This is an alpha, and two defaults deserve to be read as warnings rather than
footnotes:

• Server authentication is bootstrap-level. There is no mail channel, so an
  operator creates accounts and issues single-use login codes with
  buildmax-server user create and user login-code. Self-registration is
  closed by default. There is no password, second factor, SSO, or recovery
  flow; putting the Portal on a network you do not control requires wiring a
  real identity provider first.
• The bash sandbox is off by default, and worker hardening is incomplete.

SECURITY.md lists both, along with how to report a vulnerability privately.
Interfaces and deployment guidance may change before a stable release.

Added

• Desktop offers rewind and fork through a History button in the chat status
  bar: one list of messages, with a tab for whether choosing one moves this
  conversation back or starts a new session from it. Each names the tools that
  ran in the span you are choosing across, because their effects stay on disk
  either way. Both are refused while a run is in flight, and say so.

• /fork in the TUI branches a new session off an earlier message and switches
  to it, leaving the original untouched — for trying a second approach without
  losing the first. The two are independent from that point on, so deleting one
  never affects the other. It shares the picker /rewind uses, and names the
  tools that ran after the fork point, because their effects are on disk and the
  new session's history will not mention them.

• CLI and Desktop now keep a login's access and refresh tokens in the
  operating system's credential store (Keychain, Credential Manager, Secret
  Service) instead of as plaintext in auth.json. A file written before this
  change is moved on first read, and a machine with no usable credential store
  falls back to the file as before; buildmax login, buildmax whoami, and
  buildmax doctor say which one a login is actually using. Set
  BUILDMAX_CREDENTIAL_STORE=file to keep the previous behavior.

• /rewind in the TUI moves the conversation back to an earlier message. It
  says which tools ran in the part you are about to drop before you choose, and
  again afterwards, because rewinding moves the conversation and does not undo
  the files it wrote or the commands it ran. Nothing is deleted: the messages
  you rewind past stay on disk, and the next reply starts a new branch.

• The CLI TUI and Desktop now end a turn with a dim recap of what it did, and
  offer the answer you are likely about to type as ghost text in the input box
  when the agent asks you something — tab accepts it. Neither enters the
  conversation. Configure with agent.turn_digest in settings.yaml.

Changed

• ./make help now lists every command, grouped by what it is for, with the
  contributor path under it. It used to open on six commands and keep the rest
  — including eval, models, and the deployment tasks — behind
  ./make help all, which is now an alias for the same list.

• Enabling or disabling a catalog model with buildmax-server model enable or
  model disable now records the model's name in the audit trail, which the
  equivalent /api/admin route already did. The trail distinguishes a catalog
  change by who made it, not by where it was made.

• Each session is now a folder under sessions/<id>/ holding its metadata, an
  append-only conversation journal, and its own run traces, replacing the single
  JSON file per session and the traces/ root. The conversation is written as
  it happens rather than rewritten after each reply, so an interrupted run keeps
  everything up to the moment it stopped, and BuildMax can tell a tool call that
  never started from one that may already have changed something. A session can
  be open in one place at a time; opening one already in use says so instead of
  letting two runs overwrite each other. Sessions from earlier versions are not
  migrated and are ignored.

Fixed

• Session files and the session index are now replaced atomically, so a crash,
  a full disk, or a machine failure part-way through a save leaves the previous
  conversation intact instead of an unreadable file.

• Prevented stale-run recovery and late worker reports from overwriting a task
  run's committed outcome or leaving its task and artifact list out of sync.

• The Compose stack derives cors_origin from BUILDMAX_PORTAL_PORT through
  the new BUILDMAX_CORS_ORIGIN override, so moving the Portal off 8080 — to
  run it beside a kind cluster, which cannot move — no longer needs a hand edit
  of server.yaml to keep the browser from blocking every request.

• A team membership record with no role is now read as a member everywhere.
  Team-scoped routes previously refused such a record entirely while resource
  routes admitted it, so the same account could be a member for one request and
  a stranger for the next. No release could create one, so this affects only a
  database written before the role was defaulted.

• A background run on a deployment that leaves worker.llm.model unset reaches
  the deployment's default model again. The run was assembled with no model at
  all and failed with model not found: ""; naming a model in worker.llm was
  the only way around it.

• Starting an Issue's assigned Agent no longer leaves an empty conversation
  behind when the run is refused. A team at its quota limit collected one on
  every attempt: the conversation was created before the task, the task was
  what checked the allowance, and nothing deletes a conversation.

• openapi.json now describes every route the server registers, 117 operations
  instead of 40, and corrects the schemas that called a timestamp an integer:
  created_at, started_at, and ended_at are RFC 3339 strings, which is what
  the API has always sent. Tests now hold the document to an exact match with
  the registered routes.

• The served OpenAPI document no longer describes routes that do not exist.
  Managed inference is GET /api/llm/models and POST /api/llm/completions,
  not the team-scoped paths it listed, and listing or creating a conversation is
  team-scoped rather than /api/conversations.

• Correct model administration and kind-seeding guidance to use the
  deployment-wide catalog instead of removed aliases and managed settings.

• Fixed TUI shutdown so Ctrl+C cancels and joins the active agent run instead
  of leaving stream senders or background goroutines behind.

---

Earlier releases are in
[CHANGELOG.md](https://github...

v0.2.0-alpha.1

BuildMax is an out-of-the-box, privately deployable Agent platform: a CLI/TUI,
a desktop app, and a team Portal on one shared Go Agent Runtime.

Highlights

• The local agent can work in the background: Bash, Task, and the new
  Monitor tool detach into jobs, JobList, JobOutput, and JobStop
  inspect them, and a completion or a monitor line can wake the conversation
  in the TUI and in Desktop. Every job writes a durable, redacted event log.
• The CLI and Desktop now have exactly two modes, decided by whether you are
  signed in: local models from settings.yaml straight to their provider, or
  the models a deployment offers through its gateway. Neither mode covers for
  the other.
• Local inference through Ollama, in a local session and through a deployment
  alike, with no provider key on either path.
• Runs report what they cost: per-model pricing, per-call cost in traces,
  cache tokens on every surface that shows spend, buildmax stats for a
  session, and prompt caching as a policy rather than a boolean.
• Teams activate published plugin releases, an agent names the plugins its
  background runs load, and a worker materializes exactly those. Portal gains
  a Plugins section under Space.
• Identity and storage were rebuilt: opaque unprefixed entity identifiers,
  numeric relational keys underneath them, DATETIME(6) timestamps, and an
  API resource that names its own identifier id.

Upgrade notes

• An existing Alpha database and object store must be recreated. Opaque
  entity identifiers, numeric relational keys, text public_id columns, and
  DATETIME(6) timestamps all land in this release with no conversion
  migration. Every existing identifier, access token, refresh session, worker
  token, Portal link, bookmark, and stored object key is invalid.
• API clients that read a resource's own identifier from a type-named field
  (task_id, user_id, team_id on the resource itself) must read id.
  Relationships keep their semantic names.
• The deployment-wide worker.token is gone. Remove the secret from your
  manifests and upgrade the server before the worker image: a run dispatched
  without a run token now fails rather than falling back.
• Managed models are named by catalog name. Replace llm.aliases and
  llm.default_alias with llm.default_model, worker.llm.alias with
  worker.llm.model, and /api/teams/{team_id}/llm/... with /api/llm/...;
  a transport: buildmax entry drops team_id and names the catalog model.
• models[].transport and models[].server_url are removed from
  settings.yaml; a session's mode follows buildmax login/logout, and
  default_model names the entry a signed-out session starts with.
• The prompt_cache boolean is removed. Write cache_control: {mode: off}
  where it said false; Anthropic agent turns now cache by default.
• The server stops in order within shutdown_grace (default 25s). Deployments
  should set a matching terminationGracePeriodSeconds and preStop pause, as
  the reference manifests do.
• Native Desktop bundles are still not published by the release workflow. The
  tagged source contains Desktop; GitHub Release artifacts contain the CLI and
  server binaries.

Install

Download the archive for your platform below. Each one contains all three
binaries — buildmax, buildmax-server, buildmax-worker — plus
config-examples/, LICENSE, and NOTICE-THIRD-PARTY. Verify it against
checksums.txt first.

With a Go toolchain, for the CLI alone:

go install github.com/gougoujiang/buildmax/cmd/buildmax@v0.2.0-alpha.1

As a container, for linux/amd64 and linux/arm64:

docker pull ghcr.io/gougoujiang/buildmax:0.2.0-alpha.1

Copy config-examples/settings.example.yaml to ~/.buildmax/settings.yaml,
configure at least one model, then run buildmax for the TUI or
buildmax -p "your prompt" for a single non-interactive turn. Running the
server and Portal additionally needs MySQL and object storage; see the README.

The desktop app is not published here. It needs code signing and notarization
to launch on macOS, so build it locally with ./make build.

Before you deploy this

This is an alpha, and two defaults deserve to be read as warnings rather than
footnotes:

• Server authentication is bootstrap-level. There is no mail channel, so an
  operator creates accounts and issues single-use login codes with
  buildmax-server user create and user login-code. Self-registration is
  closed by default. There is no password, second factor, SSO, or recovery
  flow; putting the Portal on a network you do not control requires wiring a
  real identity provider first.
• The bash sandbox is off by default, and worker hardening is incomplete.

SECURITY.md lists both, along with how to report a vulnerability privately.
Interfaces and deployment guidance may change before a stable release.

Added

• A Portal agent names the plugins it loads for a background run, and loads only
  those: nothing is inherited from what its team activated. The selection
  versions with the rest of the definition, so an earlier revision still says
  what that agent named, and restoring one brings its selection back.

• Background events can wake the conversation in the TUI: run_in_background
  calls accept deliver_result to have the completion delivered as its own
  turn, and a Monitor started with react sends each delivered line back
  for analysis. Delivered payloads are marked as untrusted observations,
  recorded with non-user provenance, and never run user-prompt hooks.

• Background subagents in the TUI and Desktop: Task accepts
  run_in_background to delegate investigation without blocking the
  conversation. The final reply is read with JobOutput, the job stops with
  JobStop, and traces link the subagent run to the tool call that launched
  it.

• ./make cache-qualify checks prompt caching against a real provider. Every
  other cache test runs against a fake upstream, which proves what BuildMax
  sends and nothing about what a provider does with it — a request can be
  perfectly shaped while the provider declines to cache it, for a minimum prefix
  length, an unsupported model, or an expired retention window. The suite runs
  first write, sequential read, changed prefix, long-history lookback,
  streaming, concurrent cold starts, and retention, and prints what the provider
  reported for each. Name the target with BUILDMAX_CACHE_QUALIFY_PROVIDER,
  _MODEL, _API_KEY, and optionally _BASE_URL; it calls a paid provider, no
  check runs it, and it skips when none is named. A model entry can also name an
  integration for an OpenAI-compatible gateway whose cache behaviour has been
  qualified — none has, so every value is currently refused.

• Desktop delivers background events into the conversation: a completion
  requested with deliver_result or a react monitor line runs as its own
  turn when the owning session is on screen and idle, and is parked — not
  lost — while that session is busy or another one is open. The transcript
  labels delivered events as background observations, collapsed by default.

• Background jobs write a durable event log under <traces>/jobs/: launch
  provenance (owning session, parent run and tool call, sandbox fact),
  monitor lines with drop accounting, and the terminal state. Logs are
  redacted, bounded, and always end with how the job ended.

• ./make kind seed fills the local kind cluster's model catalog from the
  repository-root settings.local.yaml and grants the deployment's teams an
  alias for each model, so the CLI and Desktop can drive the managed transport
  against real inference. The cluster's own Portal conversations and task runs
  keep answering from the deterministic mock.

• Background commands in the TUI and Desktop: Bash accepts
  run_in_background to detach long builds, tests, or servers as local jobs,
  and the new JobList, JobOutput, and JobStop tools inspect and stop
  them. Jobs pass the normal permission and sandbox checks before detaching
  and end with the application.

• Local models through Ollama: provider: ollama on a model entry calls a
  local daemon's own API with no api_key at all. It sends the context window
  on every call, so the daemon no longer applies its own default and quietly
  truncates the system prompt and tool definitions out of a longer request —
  the failure that made small local models look like they could not call tools.
  buildmax init --ollama writes the entry, buildmax models --local lists
  what is installed and which models can call tools, and buildmax doctor
  reports a daemon that is not running or a model that is not pulled with the
  command that fixes it.

• A deployment can serve a local Ollama model: --provider ollama on
  buildmax-server model add, or provider: ollama under
  conversation.model, with no credential in either place. Real inference and
  real tool calls reach the gateway, the llm_call ledger, and quota without a
  provider key or a bill. The daemon stays on the host — a pod cannot use the
  host's GPU — and the deployment names an address that reaches it, which under
  Docker Desktop is host.docker.internal.

• New Monitor tool in the TUI and Desktop: watch logs, files, or CI by
  running a command whose stdout lines become bounded events. Lines are
  rate-limited and truncated, dropped lines are counted, and the watcher
  passes the same permission and sandbox checks as Bash.

• OpenAI Responses calls now carry a scoped prompt_cache_key, and can ask for
  24-hour retention with cache_control: {ttl: 24h}. The API caches on its own
  either way, so the key does not turn caching on — it decides which prefixes
  are looked up together, which matters because callers sharing a credential
  otherwise share one bucket. The key is derived from the credential, the model,
  the team on a managed call, and fin...

v0.1.0-alpha.2

BuildMax is an out-of-the-box, privately deployable Agent platform built on
one shared Go Agent Runtime. The same runtime backs a CLI/TUI for local
terminal work, a desktop app, and a team Portal served by the Go server,
with a scheduler and worker pipeline for background task runs.

Install

Download the archive for your platform below. Each one contains all three
binaries — buildmax, buildmax-server, buildmax-worker — plus
config-examples/, LICENSE, and NOTICE-THIRD-PARTY. Verify it against
checksums.txt first.

With a Go toolchain, for the CLI alone:

go install github.com/gougoujiang/buildmax/cmd/buildmax@v0.1.0-alpha.2

As a container, for linux/amd64 and linux/arm64:

docker pull ghcr.io/gougoujiang/buildmax:0.1.0-alpha.2

Getting started

Copy config-examples/settings.example.yaml to
~/.buildmax/settings.yaml, configure at least one model, then run
buildmax for the TUI or buildmax -p "your prompt" for a single
non-interactive turn. Running the server and Portal additionally needs
MySQL and object storage; see the README.

The desktop app is not published here. It needs code signing and
notarization to launch on macOS, so build it locally with ./make build.

Before you deploy this

This is an alpha, and two defaults deserve to be read as warnings rather
than footnotes:

• Server authentication is bootstrap-level. There is no mail channel, so
  an operator creates accounts and issues single-use login codes with
  buildmax-server user create and user login-code. Self-registration is
  closed by default. There is no password, second factor, SSO, or recovery
  flow; putting the Portal on a network you do not control requires wiring a
  real identity provider first.
• The bash sandbox is off by default, and worker hardening is
  incomplete.

SECURITY.md lists both, along with how to report a vulnerability
privately. Interfaces and deployment guidance may change before a stable
release.

v0.1.0-alpha.1

BuildMax is an out-of-the-box, privately deployable Agent platform built on
one shared Go Agent Runtime. The same runtime backs a CLI/TUI for local
terminal work, a desktop app, and a team Portal served by the Go server,
with a scheduler and worker pipeline for background task runs.

Install

Download the archive for your platform below. Each one contains all three
binaries — buildmax, buildmax-server, buildmax-worker — plus
config-examples/, LICENSE, and NOTICE-THIRD-PARTY. Verify it against
checksums.txt first.

With a Go toolchain, for the CLI alone:

go install github.com/gougoujiang/buildmax/cmd/buildmax@v0.1.0-alpha.1

As a container, for linux/amd64 and linux/arm64:

docker pull ghcr.io/gougoujiang/buildmax:0.1.0-alpha.1

Getting started

Copy config-examples/settings.example.yaml to
~/.buildmax/settings.yaml, configure at least one model, then run
buildmax for the TUI or buildmax -p "your prompt" for a single
non-interactive turn. Running the server and Portal additionally needs
MySQL and object storage; see the README.

The desktop app is not published here. It needs code signing and
notarization to launch on macOS, so build it locally with ./make build.

Before you deploy this

This is an alpha, and two defaults deserve to be read as warnings rather
than footnotes:

• Server authentication is bootstrap-level. There is no mail channel, so
  an operator creates accounts and issues single-use login codes with
  buildmax-server user create and user login-code. Self-registration is
  closed by default. There is no password, second factor, SSO, or recovery
  flow; putting the Portal on a network you do not control requires wiring a
  real identity provider first.
• The bash sandbox is off by default, and worker hardening is
  incomplete.

SECURITY.md lists both, along with how to report a vulnerability
privately. Interfaces and deployment guidance may change before a stable
release.

v0.1.0-alpha

BuildMax is an out-of-the-box, privately deployable Agent platform built on
one shared Go Agent Runtime. The same runtime backs a CLI/TUI for local
terminal work, a desktop app, and a team Portal served by the Go server,
with a scheduler and worker pipeline for background task runs.

Install

Download the archive for your platform below. Each one contains all three
binaries — buildmax, buildmax-server, buildmax-worker — plus
config-examples/, LICENSE, and NOTICE-THIRD-PARTY. Verify it against
checksums.txt first.

With a Go toolchain, for the CLI alone:

go install github.com/gougoujiang/buildmax/cmd/buildmax@v0.1.0-alpha

As a container, for linux/amd64 and linux/arm64:

docker pull ghcr.io/gougoujiang/buildmax:0.1.0-alpha

Getting started

Set BUILDMAX_API_KEY (and optionally BUILDMAX_BASE_URL and
BUILDMAX_MODEL), then run buildmax for the TUI, or
buildmax -p "your prompt" for a single non-interactive turn. Running the
server and Portal additionally needs MySQL and object storage; see the
README.

The desktop app is not published here. It needs code signing and
notarization to launch on macOS, so build it locally with ./make build.

Before you deploy this

This is an alpha, and two defaults deserve to be read as warnings rather
than footnotes:

• Server authentication is not production-ready. There is no OTP
  delivery channel, so POST /api/login is disabled by default. The
  optional dev_login_otp setting enables a single fixed code that
  authenticates any registered email address. Putting the Portal on a
  network you do not control requires wiring a real identity provider first.
• The bash sandbox is off by default, and worker hardening is
  incomplete.

SECURITY.md lists both, along with how to report a vulnerability
privately. Interfaces and deployment guidance may change before a stable
release.