# Changelog Changes to the hosted vault first, newest at the top, then the release notes of the `mehen` command line. ## The platform ### 28 October 2026: workspaces The vault moved to workspaces: one account belongs to any number of workspaces, each with its own members, teams, projects, credentials, machines and audit, at `https://app.mehen.dev/w//`. The vault's data started fresh: machines enrolled before, credentials and projects did not carry over, and every machine enrols again in a named workspace with `mehen enrol --workspace `. The `mehen` release notes below say what changed for each version of the command line. ## mehen CLI release notes The version is printed by `mehen version --json`, with the commit it was built from. Releases are served from `https://mehen.dev/dl/`; `mehen update` installs the latest one. ### 0.3.0 Many workspaces on one machine without bending anything, an enrolment that cannot deadlock, and a CLI that checks for signed releases and installs them itself. Installed release builds with a compiled trusted release key check for signed updates automatically; a build with no trusted key updates nothing. **Getting there from 0.2.0.** Run `mehen update --json` once on each machine. A 0.2.0 `mehen` cannot check a release signature, so this one update is checked against the manifest's hashes over TLS only; every update after it is signed, and a release build with a compiled trusted key checks for them automatically from then on. Do not run the installer on a machine that already has `mehen`. The first non-observational 0.3.0 command that uses slots migrates `~/.config/mehen` in place (below); `mehen workspace list` is the local-only migration command; nothing needs re-enrolling, and credentials and projects are untouched. #### Breaking changes - **One state directory, one slot per workspace.** Workspace identity state lives under `MEHEN_HOME` (default `~/.config/mehen`); harness registrations and skill ownership remain per OS user, and update state is beside the executable: `workspaces///` for each active workspace and `pending///` while an enrolment waits. The 0.2.0 layout (the first enrolment in `~/.config/mehen` itself, the next ones in `contexts/`) is migrated by a slot-using command such as `mehen workspace list`, under a journal (`migration.json`) that resumes after a kill; device state is retained, while obsolete update-check files and the completed journal are removed. A directory that is not a slot (a hand-made `revoked-*`, say) is named by `mehen doctor` and left alone. A managed host is never migrated automatically: its owner provisions the pinned slot first. - **`MEHEN_CONFIG_DIR` is retired to an alias.** For 0.3.0 it is read as `MEHEN_HOME` when it names the root, and refused as `config_dir_retired` (exit 2), before anything is read or sent, when it names a slot, a pending slot, an old context directory, or disagrees with `MEHEN_HOME`; the refusal names the `MEHEN_HOME` to use. The alias goes in the next release: move launchers and MCP entries to `MEHEN_HOME`. On a managed host the pinned slot directory is still passed as before. - **`mehen enrol` prints the ask and exits 0.** It no longer waits in the foreground or needs to be backgrounded: relay the link, then `mehen wait enr_...` finishes the enrolment, from any shell. `--wait` keeps the old behaviour. Running `enrol` again resumes the same attempt with the same key; on an active workspace it answers `active` and changes nothing. - **Links stay alive in place.** An attempt's link lives 60 minutes and `mehen wait` renews it while it waits (same id, address and fingerprint), up to 24 hours; there is no "issue a fresh link up to three times" any more. Only a terminal `expired` means a new attempt (`mehen enrol` again). A 0.2.0 attempt migrated as pending is never renewed and expires at its old time. - **No default workspace.** `mehen workspace default` is gone. A command that needs one workspace takes `--workspace`, `MEHEN_WORKSPACE` or the checkout's `mehen.toml`, else the only workspace there is; several and nothing deciding is `context_ambiguous`. `status`, `doctor`, `ls`, `pending` and `workspace list` cover every workspace. - **`mehen status --json` lists every workspace**: `{ home, allowed, workspaces, selected, next, cli }`, each entry `active` (with a `check` from the vault that never deletes anything), `pending`, `corrupt` or `absent`. `mehen status --workspace --json` keeps a scalar one-workspace result but renames `context` to `slot`. `mehen doctor --json` is one report for the machine, each vault and each workspace, with `cli`, `migration` and `strays`. `vault_status` and `vault_doctor` return the same shapes; `vault_status` has no `enrolled` field any more. - **Status is observational.** `mehen status` and `mehen whoami` neither migrate the root nor persist display-field changes; `mehen workspace list --check` records a renamed workspace's new slug and name (only those, and only for the slot's own workspace and origin). On a legacy or resumable root they refuse with the next command to run; `mehen workspace list` performs the local migration, then status can be retried. `mehen doctor` reports the journal without migrating it. - **Listings span workspaces.** `mehen ls` and `vault_list` add `workspace` to each item, and CLI tables add a workspace column when results span more than one workspace. A slug is unique only within its workspace: pass `--workspace` or the MCP `workspace` argument on subsequent single-item operations. Aggregate pending lists also span the admitted workspaces; a singular selector limits the applicable commands. - **One MCP server for every workspace.** `mehen mcp` serves every workspace the entry's `MEHEN_WORKSPACES` allows, including one enrolled while it runs; every tool except `vault_templates` takes `workspace` (slug or id), needed only when more than one could serve. Each workspace is latched to the identity it first served; one whose enrolment changes under the server is refused until the agent restarts, while the others keep serving. `mehen setup --workspace` and the `mehen-` servers are gone: the next `mehen setup` removes the old `mehen-` entries it wrote and reports them under `removed`. - **`mehen update --json`** answers `{ current, latest, available, updated, path, result, skills? }` with `result` one of `updated`, `current`, `locked`, `held` or `rolled_back`, and `skills` the per-skill report instead of `"refreshed"`. - **The installer is for a fresh machine only.** On a machine with a verified `mehen` it prints `Already installed`, downloads nothing and changes nothing unless `--force` (a human's decision, for example after losing the only release key). Its last line is now `mehen-install: {"v":1,"result":...,"version":...,"path":...,"onPath":...,"env":...,"rc":{...}}`. It writes one guarded PATH line for zsh and bash and gives advice for other shells, and never overwrites a file it does not own. - **A wider refusal when the user's home cannot be resolved.** The managed-host marker is now read under the home directory the system's user database records for this uid (`getent passwd`, then `/etc/passwd`, on Linux; `dscacheutil` on macOS), never under `HOME`. When that lookup fails or answers something unsafe (a relative path, a symlinked or group- or world-writable component, a home not owned by this uid), state-opening commands fail closed with `key_insecure` (exit 6) instead of guessing (pure help, guide and version output does not open the managed marker), naming the uid and the fix. Only a definite "no such user" on a Linux host whose user database is the plain files is treated as unmanaged. `HOME` and `MEHEN_HOME` no longer move where the marker is read. #### New - **`MEHEN_WORKSPACES`**: a comma-separated list of slugs, `tn_` ids or `/` that this process may use. It only narrows; anything outside is `workspace_not_allowed` (exit 2), and nothing inside a process widens it. An allowed workspace not joined yet shows as `absent` with the enrolment to run. - **`mehen setup`** writes one `mehen` entry per agent and carries the shell's `MEHEN_WORKSPACES` into it whenever it is restricted (and `MEHEN_HOME` when not the default), so a restricted shell never writes an unrestricted server. `--workspaces a,b` requests a narrower entry and refuses a request wider than the calling shell; an existing wider entry is skipped until `--reset-env` rebuilds its environment. `--mcp-file ` writes `mcpServers.mehen` into any compatible JSON MCP client's file; use `--agent vscode` or `--agent opencode` for those clients' different formats. `--print [--format json|toml]` prints the entry and writes nothing. `--reset-env` rebuilds an entry's `env`, for one that still carries `MEHEN_CONFIG_DIR`. A `mehen` entry made by hand, or edited by hand after setup, is `skipped` with its reason until `--force` takes it over, still under every env check. Each agent reports `mcp` as `added`, `updated`, `unchanged`, `skipped` or `failed`, and each skill as `added`, `updated`, `unchanged`, `removed`, `external` or `failed`; setup exits 1 on any `failed`. `--remove --agent X` keeps the skills while another entry remains. - **`mehen enrol --connect `**: a connect code from the workspace's Connect an agent page claims the attempt for that member, so it lands in their own Needs you and only they can accept it. A refused code is `forbidden` (exit 5). - **`mehen workspace forget ( | --slot )`** retires one slot on this machine only, without the vault; the device stays on the Machines page until someone revokes it there. - **Self-update.** Releases are signed with a Secure Enclave release key whose public half is compiled into the binary. Installed release builds with a compiled trusted release key check for signed updates automatically; a build with no trusted key updates nothing. With a key, `mehen` checks for a release about every six hours in the background after a command and installs only a signed, newer version, with one journalled rename next to the binary. `mehen update` does it now; `--version ` selects a named signed release, while an intentional downgrade needs `--force` or a verified `--rollback`. Those local overrides still verify the release signature. `MEHEN_NO_AUTO_UPDATE=1` or `autoUpdate: false` in `settings.json` under `MEHEN_HOME` turns it off; CI and source runs never update themselves. After an update the command line uses the new version at once, and a running `mehen mcp` says in a tool result (and in `cli.mcp` of `vault_status`) that the agent should restart to load it. - **`cli_outdated`** (exit 1): the vault refuses a `mehen` below its minimum version (HTTP 426) everywhere but freeze and self-revoke. `mehen` updates itself before a command when it knows the minimum is above it, and a refusal in the middle of a command is shown once with the command to run again, never re-run. Every `/v1` answer carries `Mehen-Cli: minimum=` (with `; recommended=` when the vault sets one), and requests send `User-Agent: mehen/`. - **`mehen doctor`** gains `home`, `migration`, `on_path` and `update` rows, checks every workspace, and never migrates, writes or deletes anything. - **The docs moved to https://docs.mehen.dev.** The setup guide lives at https://docs.mehen.dev/setup.md and the skill at https://docs.mehen.dev/skill.md; the old addresses on `mehen.dev` redirect. `mehen guide` and the skill name the new address. - **`mehen version --json`** adds `build` (`release`, `dev` or null when running from source) and `helper` (`embedded` or `none`); `commit` is also null for a source run without a build stamp. On macOS the Secure Enclave helper is embedded in the binary and extracted under `MEHEN_HOME/bin` on first use; the separate `mehen-se` file a 0.2.0 install left beside the binary is removed by the first update that 0.3.0 itself installs, when it and its checksum file match. #### Fixed - Finishing the same enrolment from two processes (a backgrounded `enrol` and a `wait`) no longer revokes the device it just activated: the same key finishing twice is one success. Two different devices approved for one workspace on one machine is `already_enrolled`, which now revokes and deletes nothing and says how to keep one. - `mehen revoke` removes a slot only when the vault revoked it or says it was revoked already, so "already enrolled, revoke first" and "revoked, enrol again" can no longer point at each other; `mehen enrol` on a revoked slot starts a fresh attempt. - Locks per slot stop two enrolments committing a key and a config that do not match. - An approval granted just before a link's local expiry is no longer stranded: the record is kept until the vault says the attempt is over. - `mehen update` no longer reports skills as refreshed when some were left alone. ### 0.2.0 Workspaces. The vault now holds many workspaces, each with its own members, teams, projects, credentials, machines and audit, and every machine is enrolled in exactly one of them. **Enrolments made with 0.1.0 stop working at the cutover.** The vault's data starts fresh: every machine enrolled by 0.1.0, every credential and every project is gone, and a 0.1.0 `mehen` cannot enrol against the new vault (its enrolment names no workspace). Update (`mehen update --json`, or `curl -fsSL https://mehen.dev/install | sh`), then enrol again with `mehen enrol --workspace `. The update keeps the old enrolment's files in `~/.config/mehen`, so the new enrolment lands in `~/.config/mehen/contexts/`: make it the default with `mehen workspace default ` (which also decides what the plain `mehen` MCP server serves), verify with `mehen status --json`, and let the human delete the dead enrolment's `config.json`, `device-key*` and `ledger.json` from `~/.config/mehen`; `https://mehen.dev/setup.md` has the steps. This is forward only: a 0.1.0 `mehen` cannot be used against the new vault, so there is no downgrade. The human re-adds credentials through intake links and re-creates projects with `mehen init`. - **Workspace enrolment.** `mehen enrol --workspace ` is required; a bare `mehen enrol` is a usage error (exit 2) and sends nothing. The slug is on the workspace's Connect an agent page. The machine's owner accepts it with their passkey; `--team ` enrols a machine a team owns, which an owner or admin admits. The enrolment is verified against what was asked for before anything is written: an activation in another workspace, with another owner kind or without a complete scope writes no config: the CLI attempts to revoke the new device, reports whether that succeeded and, when it did not, names the device for a human to revoke. One enrolment per workspace per machine: the first lives in `~/.config/mehen`, the next in `~/.config/mehen/contexts/`, or wherever `MEHEN_CONFIG_DIR` points. Keys are scoped to one workspace and never reused across workspaces. - **Contexts and selection.** A context is picked before any signature: `MEHEN_CONFIG_DIR`, then `--workspace ` (a global flag) or `MEHEN_WORKSPACE`, then the checkout's `mehen.toml` (`workspace` and `vault`), then the default. New command `mehen workspace list [--check] | show | default | bind`. New local refusals, all exit 2 and never from the vault: `workspace_unknown`, `workspace_mismatch` (also for a `MEHEN_VAULT_URL` or key scope naming another origin or workspace), `context_ambiguous`, `workspace_unbound`. `mehen status` and `vault_status` name the workspace (id, slug, name), the owner and the context directory; every status call refreshes the recorded slug and name from the vault, never the id. `mehen revoke` revokes only the selected context. - **Managed-host pins.** A managed host's agent configuration must be current. An outdated one is refused as `pin_outdated` (exit 2): selection fails closed, nothing is inferred, and only the harness owner can repair it. On a managed host only the pinned `MEHEN_CONFIG_DIR` is accepted. - **Private credentials and homes.** `mehen request` and `mehen connect` take `--home private|project|workspace` (`--project ` for a project home, or the checkout's manifest project); `vault_request` and `vault_connect` take `home` and `project`. The default is `private`: only the human who fills it in can use it, through their own machines with the private-credentials tick. The human may change the home on the page. - **Overrides in `env ls`.** A member may set a personal override for a variable in an unprotected environment on the project page (their own private credential, or a plain non-secret value). `mehen env ls` marks it `override (your )` or `override (your plain value)` in its text and `override: true` in `--json`; `mehen env check --json` carries the same marker, while its human output only reports whether every variable resolves; `mehen run` names overridden variables in its banner. No value is ever printed. - **Project context for `fetch`.** `mehen fetch --project --env ` and `vault_fetch` `context: { project, environment }` name the project environment a credential is used for, which a protected credential requires, and so does a workspace credential that a team's or a guest's machine reaches through a shared project; a credential whose home is a project you may use, or your own private one, is reachable by name. A context is an extra requirement, not a default: the environment must reference a non-private credential, and a private one needs an authorised unprotected environment. It never changes the workspace. - **Links under the workspace.** Every ask link is `https:///w//...`, under the canonical slug of the workspace the machine is enrolled in. A link under another slug, an alias or another origin is refused and rebuilt from the id under the canonical slug, with a warning; a link cannot be trusted without a known slug. Asks carry `context: { origin, workspace: { id, slug, name } | null, device }`, the enrolment that raised them. - **The identity gate.** A workspace may require a verified Google identity on its domain. The vault then refuses a human who has not signed in with Google recently with `identity_required` (exit 4): the human completes the sign-in in the workspace, and the agent repeats the step. Google only identifies; passkeys still authenticate and sign. Enrolled machines are not re-gated in this release; removing a member cuts their machines off at once. New codes `account_pending`, `owner_inactive` and `project_unshared` are exit 4 as well. - **MCP.** One `mehen mcp [--workspace ]` server binds one context for its lifetime and refuses to serve anything else; `vault_env` in a checkout of another workspace is `workspace_mismatch` ("start a second server"). `mehen setup --workspace ` registers that workspace's server by its stable id, as `mehen` for the default context or `mehen-` for another, without touching other registrations; `mehen setup` with no flags writes exactly what 0.1.0 wrote. Tool names are unchanged. `mehen pending` and `vault_pending` show this machine's own asks and its own "machine added" notice only. - **Policy proposals** (`mehen policy preview|propose`, `vault_policy`) keep their surface but are refused by the vault in this release (`forbidden`, "Policy widening is not available yet"); `show`, `cancel` and `stop` work. - **Help and next steps** from the CLI itself name `--workspace ` wherever they tell you to enrol (the vault's own `next` for an unknown or revoked machine still says `mehen enrol`; add the workspace), and use neutral example names. ### 0.1.0 First public release: `mehen.dev/install`, `mehen setup`, `mehen update`, the ask block, enrolment with a kept key, `mehen mcp`, `mehen run`, templates, `mehen check` and `mehen pending`.