Releases · icloudbb/buildmax

Release list

v0.2.0-alpha.12 Pre-release

Pre-release

github-actions released this 13 Sep 12:24

v0.2.0-alpha.12

b190a7c

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/icloudbb/buildmax/cmd/buildmax@v0.2.0-alpha.12

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

docker pull ghcr.io/icloudbb/buildmax:0.2.0-alpha.12

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.

This is an alpha: server authentication is bootstrap-level and the bash sandbox
is off by default. Read SECURITY.md
before exposing the Portal.

Added

Creating, disabling, or destroying a space Secret now writes a
secret.created, secret.disabled, or secret.destroyed event to the space
audit trail, with the Secret's id as the target and no item name, value, or
ciphertext in the event.

Changed

Admin stored-flag transitions are now a single idempotent PUT .../state
instead of paired POST actions: PUT /api/admin/users/{user_id}/state
(disabled), PUT /api/admin/llm/models/{model_id}/state (enabled),
PUT /api/admin/plugins/{plugin_name}/state (archived), and
PUT /api/admin/plugins/{plugin_name}/releases/{version}/state (yanked).
The old /disable, /enable, /archive, /unarchive, and /yank routes no
longer exist; clients that ship with the server were updated in step.
Authentication routes moved under a common /api/auth/ prefix:
/api/auth/otp, /api/auth/login, /api/auth/logout, /api/auth/password,
and /api/auth/token/refresh. The old top-level paths (/api/login,
/api/otp/request, and the rest) no longer exist; clients that ship with the
server were updated in step.
The OpenAPI specification is split along the listener boundary: the public
/openapi.json no longer documents the worker control plane, which now lives
in its own openapi-worker.json. This matches the two-listener network
boundary, where the public socket cannot dispatch a worker route.

Fixed

buildmax -r <value> with a malformed (non-UUID) session id now reports an
"invalid resume id" usage error instead of the "session not found" a
well-formed but unknown id gets, matching the --session-id validation.
buildmax --session-id <uuid> now creates the session when it does not exist,
matching the flag's documented "load if exists, else create" contract, so a
caller can start a run under a deterministic id. -r/--resume still errors on
an unknown id.
The OpenAPI documents now define the Artifact schema every artifact route's
response referenced, so /openapi.json (and the worker document) no longer
carry a dangling $ref for the file a create or read returns.
The served OpenAPI document's info.version now reflects the running build
instead of a stale hand-maintained literal, so /openapi.json and Swagger UI
report the deployment's actual version.
Portal now shows "1 member" (not "1 members") for a one-member space, exposes
the agent-detail section tabs with the standard tab role, and gives the
new-secret item name and value inputs real accessible labels.
The Portal dashboard no longer issues GET /api/spaces/null/conversations on
first load, removing the 403 console error emitted on every sign-in before the
current space resolves.

Earlier releases are in
CHANGELOG.md.

Assets 17

v0.2.0-alpha.11 Pre-release

Pre-release

github-actions released this 13 Sep 04:04

v0.2.0-alpha.11

3d497c2

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

With a Go toolchain, for the CLI alone:

go install github.com/icloudbb/buildmax/cmd/buildmax@v0.2.0-alpha.11

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

docker pull ghcr.io/icloudbb/buildmax:0.2.0-alpha.11

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

Each release now attaches downloadable desktop builds — a macOS .dmg and a
Windows .exe, each with a .sha256. The bundles are unsigned during alpha,
so the install guide covers the one-time Gatekeeper and SmartScreen step.
The space audit trail now records space creation (with its quota tier),
webhook key creation and revocation, agent definition create/update/delete,
and workflow create/publish/archive/unpublish; and every event carries the
task run it was recorded on behalf of, so an investigation can pivot between
an audit event and the run that caused it.
A server can now expire old run traces: server.yaml trace.retention_days
(0, the default, keeps every trace forever) runs an hourly sweep that removes
the trace of a run that ended longer ago than the window and records a
traces.pruned audit event, so a trace missing by policy is distinguishable
from one that was lost.
Portal Run Details now shows how a worker run's MCP transports were treated —
that stdio is disabled by the unattended-worker profile and which remote
transports the run resolved — beside the sandbox boundary, recorded in the
run's trace. An older trace reads as unknown rather than as stdio-allowed.
The Workflow step form can now add, name, and remove a step's input bindings
to an earlier step's output, so passing one Agent's result to the next no
longer requires hand-editing the definition JSON.
A Workflow step can now take an earlier step's output as input. A step
declares bindings naming a prior step, and the run feeds that step's full
output to the downstream Agent as labelled, untrusted context — so a
multi-step Workflow can pass one Agent's result to the next.

Changed

The Portal's mutable Space file surface is now named Files everywhere
(sidebar, breadcrumb, page title, and contextual links), renamed from
"Workspace Files"; its route is unchanged.

Fixed

On narrow screens, the Portal's compact header no longer shows a fabricated
"My Space" when the current Space cannot be resolved; it now shows the same
loading/unavailable state label the sidebar uses.
A task that fits within a Space's run limit is no longer refused for the
tokens its auto-generated title spent, so starting one no longer leaves an
empty conversation behind on a token-quota refusal.
Fixed the Portal task view briefly showing a previous turn's reply before the
new run's output arrived: the live output stream is now scoped per run, so a
finished run's buffered text is never replayed to the next turn's watchers.
Editing, publishing, or restoring a Workflow while someone else edits it now
returns a conflict to the later save instead of silently overwriting the newer
definition or failing with an internal error.
A Workflow run no longer stalls when a step finishes but its completion
signal is lost or the server restarts: a background recovery loop reconciles
due runs from stored state, advancing them without the callback.
A Workflow run now completes when its step finishes: the server's terminal
callback reads the finished step's result and advances the run, instead of
leaving every run stranded in "running".

Security

Unattended worker runs now reject stdio MCP servers before any child process
or model call, since a worker would launch them outside its sandbox; configure
a remote (http or sse) transport instead. CLI, Desktop, and evaluation runs
keep stdio.

Earlier releases are in
CHANGELOG.md.

Assets 17

v0.2.0-alpha.10 Pre-release

Pre-release

github-actions released this 12 Sep 03:24

v0.2.0-alpha.10

c3f1e5e

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

With a Go toolchain, for the CLI alone:

go install github.com/icloudbb/buildmax/cmd/buildmax@v0.2.0-alpha.10

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

docker pull ghcr.io/icloudbb/buildmax:0.2.0-alpha.10

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 Space can run an Agent on a recurring cron schedule: create, list, edit,
enable/disable, and delete schedules under
/api/spaces/{space_id}/schedules, and each due time starts one Task
automatically.
buildmax info --json now reports a per-turn usage and cost breakdown under
stats.turns, recorded in the session file so a session describes what each
turn cost from its own record.
buildmax usage sums token and cost totals across your local sessions,
grouped by day, workspace, or model and narrowed with --since, so a week of
use answers as one figure instead of one session at a time.

Changed

The project moved to the icloudbb GitHub organization. The Go module path
is now github.com/icloudbb/buildmax, container images publish to
ghcr.io/icloudbb/buildmax and ghcr.io/icloudbb/buildmax-portal, and the
old gougoujiang GitHub and GHCR locations remain read-only for one Alpha
cycle. Update imports, go install targets, and image references.

Fixed

The Read tool now reports (file is empty) after successfully reading a
zero-byte file instead of returning indistinguishable empty output.
Schedules now accept any IANA timezone (for example Asia/Shanghai), not only
UTC: the server binary embeds the timezone database, so a named zone resolves
in container deployments that ship no system zoneinfo.
On a multi-replica Server, a conversation turn whose coordination lease
expired and was taken over can no longer write behind the new holder: message
writes now carry the lease's fencing token and a stale one is rejected.
Write now reports the resolved file path and number of UTF-8 bytes written on
success, making its result directly verifiable by the agent.

Earlier releases are in
CHANGELOG.md.

Assets 13

v0.2.0-alpha.9 Pre-release

Pre-release

github-actions released this 10 Sep 09:05

v0.2.0-alpha.9

a0e9133

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

With a Go toolchain, for the CLI alone:

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

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

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

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 admin account list can be filtered by whether an account is enabled,
whether it has set a password, whether it holds a system role, and the
platform it last signed in from — in Portal and on GET /api/admin/users
(status, has_password, system_role, platform) — so an operator can
work a specific set without paging through everyone.
buildmax admin gained model list, model add, model enable, and model disable: managing the deployment's model catalog over the authenticated Admin
API, the automation peer of the Portal Models area. model add sends the
provider key in the request body only; it is stored encrypted and never read
back, and a deployment with no encryption key configured refuses a model that
carries one.
buildmax admin gained user list, user create, user login-code, user disable, and user enable: managing deployment accounts over the
authenticated Admin API, the automation peer of the Portal Accounts area.
Creating an account and issuing a login code stay separate steps, and there is
no set-password — a login code lets the person choose their own password.
Added POST /api/admin/llm/models, so a System Administrator can add a
managed model through the admin API rather than only buildmax-server model add. It takes the same fields, and api_key is write-only: accepted in the
request body, stored encrypted at rest, and returned by no read. Adding a
model that carries a credential requires a configured encryption key.
A System Administrator can list an account's live login sessions and revoke
one of them — signing a single device out while the account's other sessions
keep working — through GET and DELETE /api/admin/users/{user_id}/sessions/ {session_id}. The listing carries only safe metadata (session id, platform,
and timestamps), never a token.
buildmax admin list, buildmax admin grant <email>, and buildmax admin revoke <email> manage deployment administrators from the signed-in CLI over
the same API the Portal uses, so routine administration no longer needs shell
access to the server's database (which buildmax-server admin still holds for
first-time and lockout recovery).
A background sweep reclaims checkpoint payloads that no checkpoint references
and that are older than a grace period — the bytes a worker uploaded when a
finalize failed or a worker died before committing the pointer — so orphaned
workspace-checkpoint objects no longer accumulate. The grace is set with
storage.checkpoint_orphan_grace_days (0, the default, reclaims on the next
hourly sweep).
The in-Portal help center now offers a Simplified Chinese translation of the
whole manual, with an EN / 中文 switch in the Help sidebar; the choice is
remembered per browser and defaults to the browser's language.
A coordination server setting shares live streaming, connection events, and
conversation turn serialization across replicas through Redis, so a deployment
can run more than one server replica correctly; mode: local (a single
replica) stays the default, and mode: redis fails closed when Redis is
unreachable.
The Portal Accounts list now pages through every account with Previous and
Next controls and a "1–50 of N" position, so a deployment with more than one
page of accounts is fully reachable rather than stopping at the first fifty.
Portal gains an Administrators section for managing who can operate the
deployment — list active grants (and revoked history), grant an account by
email, and revoke — and, for a confirmed administrator, Administration moves to
a first-level sidebar destination. The Overview now shows the caller's own
grant and a read-only view of the effective configuration.
The Portal has a built-in help center: a Help icon in the top bar (and the
user menu) opens an end-user manual covering getting started, the CLI and TUI,
models and tools, extending the agent, safety, and the Portal itself. The pages
are plain Markdown under the repository-root help/ directory and are baked
into the portal image at build time, so the manual ships with the app and needs
no separate site.
The Portal admin Models area now has an "Add a model" form, so a System
Administrator can add a managed model without the server command line. The API
key is a password field, sent only in the request body, stored encrypted, and
never shown again; it is cleared as soon as the model is added. A deployment
with no encryption key configured reports that it cannot accept a credential.
Portal now shows a real not-found page for an unrecognized address instead
of silently opening Chat, and Agent, Workflow, Workflow Run, Task, and
Issue detail pages distinguish a deleted resource from one you don't have
access to.
A run's detail now shows the plugin releases it actually resolved and the
artifacts it published, both read from the same authoritative records a
retry and an issue's output list already use.
The Portal "Run details" view now shows what became of a run's workspace: a
Workspace section reports whether the run restored its base checkpoint and
whether its result checkpoint committed, with the bounded reason on a failure,
so an operator can see a run's continuity state without reading the database.
The Portal account detail now lists an account's live login sessions —
platform and timestamps — and an operator can revoke one of them, signing a
single device out while the account's other sessions keep working, alongside
the existing revoke-everything action.
Added a complete Simplified Chinese mirror of the design records, with
per-page language navigation and automatic synchronization checks.
A TaskRun's durable trace now records who or what started it and why
(created_by, created_by_type, trigger_source, retry_of_task_run_id) on its
run_start line, so a downloaded trace explains its own origin.

Changed

Portal task runs now execute in a single workspace/ directory — the agent's
working directory, holding the space's files — instead of splitting them into
separate read and output directories. Files an agent means to keep are
published with UploadArtifact; the run's reply is still recorded as its
result.
The end-user manual now lives only in help/, the same pages the Portal
serves under Help; the duplicate copies under docs/ (the old guide/ and
start/ directories and the CLI reference) are gone, so docs/ is now
contributor, operator, and design material.
Issue owner and executor are now independent fields instead of one combined
assignee, so an issue can have an accountable person and a selected Agent or
Workflow at the same time. owner_id replaces the person case of the old
assignee_kind/assignee_id pair, and executor_kind/executor_id
replace the agent and workflow cases.
Working a space issue locally moved from the buildmax --issue <id> flag to
the buildmax issue start <id> subcommand, alongside issue list, show, and
status. It takes the same run flags as buildmax itself (-p, --model,
--workspace, and so on).
Expand ./make kind fixtures with shared-space roles, invitations, assigned and nested issues, workflow states, files, artifacts, synthetic secrets, and pagination data. Add --runs for free-mock conversation and Task/Workflow history, and repair incomplete comment seeding without duplicating existing fixtures.
Managed-model provider credentials are now encrypted at rest, under the same
deployment key-encryption boundary that protects Space Secrets. Adding a model
that carries a credential (via buildmax-server model add) now requires a
configured encryption key (secret.kek_file); without one the credential is
refused rather than stored in the clear. Credential-free models (for example
an Ollama target) are unaffected. Existing plaintext credentials are not
migrated — re-add those models once an encryption key is configured.
Opening an account in the Portal admin area now puts it in the URL
(...

Assets 13

v0.2.0-alpha.8 Pre-release

Pre-release

github-actions released this 06 Sep 08:14

v0.2.0-alpha.8

8397b56

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

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

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.

##...

Assets 13

v0.2.0-alpha.7 Pre-release

Pre-release

github-actions released this 02 Sep 07:58

v0.2.0-alpha.7

1b71969

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

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

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...

Assets 13

v0.2.0-alpha.6 Pre-release

Pre-release

github-actions released this 29 Aug 11:11

v0.2.0-alpha.6

2a2a238

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

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

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...

Assets 13

v0.2.0-alpha.4 Pre-release

Pre-release

github-actions released this 29 Aug 03:00

v0.2.0-alpha.4

645a6fc

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

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

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.

Assets 13

v0.2.0-alpha.3 Pre-release

Pre-release

github-actions released this 29 Aug 02:13

v0.2.0-alpha.3

2451c8b

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

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

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 ...

Assets 13

v0.2.0-alpha.2 Pre-release

Pre-release

github-actions released this 26 Aug 00:41

v0.2.0-alpha.2

099ce29

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

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

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...

Assets 13

Uh oh!

Releases: icloudbb/buildmax

Release list

v0.2.0-alpha.12

Install

Added

Changed

Fixed

Uh oh!

v0.2.0-alpha.11

Install

Before you deploy this

Added

Changed

Fixed

Security

Uh oh!

v0.2.0-alpha.10

Install

Before you deploy this

Added

Changed

Fixed

Uh oh!

v0.2.0-alpha.9

Install

Before you deploy this

Added

Changed

Uh oh!

v0.2.0-alpha.8

Install

Before you deploy this

Added

Changed

Uh oh!

v0.2.0-alpha.7

Install

Before you deploy this

Added

Changed

Fixed

Security

Uh oh!

v0.2.0-alpha.6

Highlights

Upgrade notes

Install

Before you deploy this

Added

Changed

Uh oh!

v0.2.0-alpha.4

Highlights

Upgrade notes

Install

Before you deploy this

Security

Uh oh!

v0.2.0-alpha.3

Highlights

Upgrade notes

Install

Before you deploy this

Added

Changed

Fixed

Uh oh!

v0.2.0-alpha.2

Highlights

Upgrade notes

Install

Before you deploy this

Added

Changed

Fixed

Uh oh!