[immakermatty]

Motivation

Root decision 0198 (points 1, 2, 4, 6 and 7, with 0197 points 3 and 7–9) gives every Environment its own vault: its own organization in its network's Lazurio Vaultwarden, created and held by the Environment's technical account and remembered by ID. Until now (decision F43) an Environment was a member of a person's organization: an Admin invited a guessed address vaultwarden@<address> into a collection, confirmed the member by its fingerprint, and the Environment recognized its collection partly by name. This PR replaces that model in the Platform (DEV-6631 task 638 part A, contract C3).

Target state

• The account and the vault come from the handover. The optional, closed handover member vault: {server_url, account, name} (contract C2), which Machines writes only for a Platform that reads it, names the network's vault, the technical account the network pre-allowed for this Environment (vaultwarden-<26 base32>@<Environment address>) and the vault's name. Without it the Environment has no vault yet and says so (unsupported, no-vault). Nothing is guessed: no vaultwarden@<address>, no vault derived from Headscale, no collection-name match (including the "·" name).
• The Environment creates its vault. lazurio vault setup (and the installed Launchpad at its start, by Executor's pattern) installs the pinned bw, registers the account (the existing flow), logs in with its API key (client_credentials) and creates the organization with POST /api/organizations: the organization key RSA-OAEP-encrypted to the account's own public key (derived from its own private key), the organization key pair with its private key wrapped by the organization key, the billing e-mail (the account), the name vault.name and a first collection "Agenti", its name encrypted with the organization key. It records the organization and Agenti by ID and renames the organization when vault.name changes. A creation is never sent twice: its receipt (the new organization's public key, with the time, recorded before the request) is resolved first. While it is unresolved, every setup looks for the organization carrying that key among the account's memberships of any status and sends no new creation; found nowhere (an answer lost, a profile that lists it late, a request that arrives late), the setup reports creating and the next one looks again. Only a receipt older than 15 minutes (a request times out at 30 s) that still matches nothing is taken for a creation that never happened: discarded (journal receipt-expired) and the vault created once. A creation refused by the vault's answer discards its receipt at once. A recorded organization that is gone, or a refused API key, is revoked and never replaced.
• One shared unlocked bw session for agents, unchanged.
• The agents use it from the start (0198 point 1). The setup in which the vault becomes ready (its collection Agenti recorded) turns "Používají agenti" on for bitwarden in the Environment's Folder, at the Launchpad's start as with lazurio vault setup: the same change the switch makes, refused as the switch is where the tool is not offered or the Organization does not allow it. Once per vault: a person may turn it off and it stays off, because no later setup (a new session after a restart, a rename, a repair) turns it on again; a failure is journaled (agents-not-enabled) and never fails the setup. The page no longer turns the switch on itself.
• No bw ever runs without its own data directory (bw rewrites its store on every start, so a run without one rewrites a default profile, a person's own included). bwCli, through which every bw of the vault runs (setup, status, refresh, env's unlock, secrets, the pilot subset, the installer's version check), now refuses before anything runs unless the binary and the data directory are absolute paths, and sets BITWARDENCLI_APPDATA_DIR last on every run so no step can replace it. The one other path that starts a bw, the version probe of Settings → Tools, already gives it a fresh mkdtemp directory (the catalog's isolatedData), removed afterwards; a test now pins both.
• The Tools row shows only the state and "Otevřít trezor" (<server_url>/#/vault?organizationId=<id>), plus one action only where a setup moves the vault on ("Nastavit", "Zkusit znovu", as the wireframe's unreachable state does). No dialog, no details, no disconnect. Czech copy is formal and minimal.
• Pilot safety. Environments connected the 0197 way keep working read only while their handover names no vault: status connected, the shared session unlocked, module secrets (F46) from the recorded collection. This frozen subset lives alone in src/vault/legacy-0197/, whose README names its deletion condition (every handover carries vault and task 649 has moved the items). When the handover gains vault, the new flow runs with the new account in its own directory and the pilot's directory stays untouched.
• F46 reads the own vault: the one item named exactly like the secret anywhere in it (login.password). On a work Environment the owning Organization's apps read it; on a personal Environment the Personalspace's modules do (0198 point 4); everything else is refused with a clear reason (other-organization, personalspace, personal-environment).

What changes

• src/machine/: the handover schema of Machines v0.12.159 (the merge of Apps → Trezor only where a vault is: the entry follows the vault core's answer (F36/F53 addendum, DEV-6612) #500, 8b66889b; adds only vault, with a work and a personal account shape), vendored byte for byte with its provenance; MachineVault type.
• src/vault/: host.ts (enableVaultForAgents: the switch's own Folder change at the current revision, retried on a busy or meanwhile-changed Folder as the Organization's settings are), flow.ts (enableForAgents, called once by the setup in which the vault becomes ready, outside the account's lock), bw.ts (the data-directory guard), context.ts (facts from the member only), store.ts (custody keyed by the account; the own record {organizationId, collectionId, pendingKey}, unreadable → refused), register.ts (vaultRequest with PUT/DELETE, apiKeyLogin, unlockPrivateKey, publicKeyOf), new organization.ts (create, recognize by receipt, find Agenti by ID, rename), new session.ts (the one shared session and the secret read, shared with the pilot subset), new status.ts (the answers), flow.ts (status, setup, refresh, env, secrets; setUpAtStart), host.ts, cli.ts (env|status|refresh|setup), bw.ts (no fingerprint step; items by organization); new legacy-0197/ (frozen pilot read path + README).
• Launchpad: vault-routes.ts (status, refresh, setup with a job; atStart), server.ts and cli.ts/update/cli.ts (vaultAtStart, the Executor rule; the Folder's switch for a given host), vault-view.ts and vault-panel.ts (state, link, one action), tools-panel.ts (after a followed setup ends connected the page reads the Folder again; it never toggles the switch itself), the dialog and its CSS removed from index.html, messages (formal Czech, minimal).
• F46: runtime-secrets.ts hands the module's kind to the vault, which decides; the catalog's check follows the same rule; texts name the vault, not a collection.
• Agents: the bitwarden catalog entry (minimal, correct; room left for task 652's a/b/c), template revision base-instructions-49 (Copy: address people formally (vykání) in Launchpad, shell, CLI and agents' speech #328's vykání took 48); the tool's purpose, which the Launchpad also shows, keeps Copy: address people formally (vykání) in Launchpad, shell, CLI and agents' speech #328's neutral wording ("Co v něm je, smějí agenti použít bez ptaní.").
• Recovery evidence withholds vault.account, vault.name and the vault's host.
• Docs: new decision F53 (supersedes F43's collection model, amends F46; F52 is the module generator's, Modules: one module generator in the Platform, with the personal form (M2 1/3, #359) #394), environment-tools.md, launchpad-development.md, machine-handover.md, recovery.md, public-development.md, module-adoption.md.

What deliberately does not change

• Správci membership (638b), Nastavení → Trezor (648), secret requests (651), the full Folder guidance (652), Dashboard, releases.
• The session model, the pinned bw 2026.7.0 and its installer, F43's custody form.
• The agents' switch stays a switch a person can turn off (the wireframe keeps it); only the vault's first readiness turns it on.

Verification

• bun run check on head 7eab1559823f520a841edad92db545f851f4e906 (rebased on main a9f80c7, with Copy: address people formally (vykání) in Launchpad, shell, CLI and agents' speech #328): Biome, tsc, the public guard, the proof build and smoke, then 3490 pass, 8 skip, 1 fail (10 min): the one failure is a flake of main itself, untouched here (Flaky: launchpad-prompts expects no GitHub call before admission, but the Launchpad's start peeks the Personalspace holder in the background #413: tests/launchpad-prompts.test.ts expects no GitHub call before admission while the Launchpad's start peeks the Personalspace holder in the background; 7 of 10 runs of that file fail on plain main a9f80c7 locally, 6 of 10 on this branch). CI on this head: green (static checks, both Linux test shards, check (ubuntu-24.04)) on the third attempt of tests (2/2); its first two timed out in tests/shell-artifact.test.ts, whose second build's bun build child hung (untouched here; Flaky on Linux CI: shell-artifact's second build hangs in its bun build child (contract.js) until the 60 s bound #414), and the third passed (1.1 s).
• Earlier heads, before the rebase: 3425e71 (the review fix) 2623 pass, 0 fail, CI green; 88c382d (the agents' switch and the bw data-directory guard) 2621 pass, 0 fail; a4bb8f3 2619 pass, 0 fail.
• On Linux, where a Folder offers the vault (on 88c382d): tests/launchpad-vault.test.ts, tests/vault-flow.test.ts and tests/vault-store.test.ts in a Linux container (oven/bun:1.4.2, the temporary directory on ext4 as the Folder's lock requires): 26 pass, 0 fail, including the Launchpad's Folder switch test, which macOS skips. CI's Linux shards run them too.
• New and rewritten tests against the real consumers (startLaunchpad over HTTP, runVaultCommand, createModuleOperations) and the fake Vaultwarden extended with the API-key login, the profile and the organization endpoints: tests/vault-flow.test.ts (17, including the agents' switch turned on once per vault, the review's reproduction (a lost answer, then one profile without the organization: creating, one organization, found on the next run) and a receipt that matches nothing making exactly one organization after its bound), tests/vault-organization.test.ts (2, including the account opening its own organization key from its master password down to Agenti's name and the organization's private key), tests/vault-pilot.test.ts (6, the pilot with and without vault, its directory untouched), tests/vault-cli.test.ts, tests/launchpad-vault.test.ts (routes, the setup at start, and the Folder's switch on Linux), tests/vault-handover.test.ts (the member, a missing or invalid member, an earlier Platform refusing a handover with it, the binding, redaction), tests/vault-secrets.test.ts, tests/runtime-secrets.test.ts, tests/module-runtime-secrets.test.ts (a Personalspace module reading its secret on a personal Environment end to end), tests/vault-view.test.ts, tests/vault-context.test.ts, tests/vault-host.test.ts, tests/vault-store.test.ts (with bw refused without its own data directory and the Tools probe's temporary one, and the receipt's time required in its one form), tests/vault-register.test.ts. No value or token on argv (the fake bw logs $HOME/bw.calls), in the journal or in an answer.
• In a browser (decision 0178), throwaway Launchpads of this branch with the fake vault, Settings → Nástroje. The row: "Hesla a další položky pro agenty.", "Připojeno", and its only control "Otevřít trezor" (https://vaultwarden.example.lazurio.io/#/vault?organizationId=<id>, new tab, noopener noreferrer). The switch, on Linux in a personal Remote Environment's Folder with bitwarden offered and off: the Launchpad's start set the vault up while the row followed the job ("Instaluje se Bitwarden…", switch off), it ended "Připojeno" with the link and the switch on (aria-checked="true", the Folder's selection ["bitwarden"]); turned off by a click, it stayed off through a later setup of the same vault (its session lost: connected, locked → setup → connected, enabled: false). A creation that never reached the vault (on 3425e71): the row read "Trezor se zakládá" with "Zkusit znovu" and the switch off, and "Zkusit znovu" ended in the same state without a second creation. (The not-allowed/no-vault lines are covered by tests/vault-view.test.ts and the HTTP tests, not opened in the browser.)
• End to end against the real image (on a4bb8f3, before the review's three commits) ghcr.io/lazurio/vaultwarden:1.37.4-lazurio.1@sha256:68da93bb…f492 (amd64 under Rosetta, OrbStack, own container prefix and port, TLS with a throwaway CA) and the real pinned bw 2026.7.0 for macOS arm64, downloaded and verified by the core's own installer, driving this branch's core: /admin/invite pre-allowed the account; setup connected in 21 s (install → account → vault → sign-in); the account is the vault's only, confirmed Owner and a member of nothing else; the vault has exactly one collection, the recorded Agenti; the real bw sync and bw list collections showed "Agenti" (bw opened the organization key itself); an item created in Agenti was read back by the core as a runtime secret; a new name renamed the same vault; a setup again kept one vault; no secret in 28 bw argv lists or the 7 journal entries. 17 of 17 checks; the container, volume and the run's state were removed afterwards. The Linux bw binary was not exercised here.

Risks, open questions, follow-ups

• Schema pin. The vendored handover schema is Machines v0.12.159's (the merge of Apps → Trezor only where a vault is: the entry follows the vault core's answer (F36/F53 addendum, DEV-6612) #500, byte-identical to its head and to Machines main, SHA-256 76a05804…). Machines writes vault only for a Platform at or above the release carrying this PR (its version gate).
• Rebased onto Copy: address people formally (vykání) in Launchpad, shell, CLI and agents' speech #328 (formal address): its edits of the vault messages this PR removes are gone with them, the template revision is base-instructions-49 with its digest pinned again, and the vault decision is F53 because main gave F52 to the module generator. The stacked Vault: an agent's secret request and the agents' guidance (root decision 0198 point 9, DEV-6631 tasks 651 and 652) #401 and Vault: Nastavení → Trezor and the Správci of the Environment's own vault (DEV-6631 tasks 648, 638b) #402 name the vault decision F52 (and Vault: an agent's secret request and the agents' guidance (root decision 0198 point 9, DEV-6631 tasks 651 and 652) #401 its own F53); they follow with F53 and F54.
• collection-unknown. An organization recognized only by its receipt that meanwhile got more collections is not given an Agenti by guess; it needs an agent or a person (rare: only if the answer to the creation was lost and someone added collections before the next setup).
• Revoked is terminal here. A deleted vault or a disabled account is reported, not recreated; recovery is the network operator's.
• Org creation is open to every account (ORG_CREATION_USERS); noted in F53's limits, as SHAPING says.
• Review fix (2026-10-14): a saved receipt did not stop another creation when the profile briefly omitted the new organization (the review's reproduction: two organizations, the first orphaned). Fixed as above: an unresolved receipt fails closed (creating), with the 15-minute bound as the only way to a new creation.
• Receipt bound. A vault that kept a new organization out of the account's profile for more than 15 minutes would get a second one. Vaultwarden creates the creator's confirmed Owner membership in the same request, so only a vault hiding it that long could cause it.
• Decided in review (2026-10-13): the setup turns the agents' switch on when the vault becomes ready (above); revoked stays terminal with no in-product way back, and the operator's recovery line (a new account in the handover gives a fresh vault) goes into the Machines PR's runbook.
• Stacked work. Two follow-up PRs build on this branch (Nastavení → Trezor with Správci, and secret requests with the Folder guidance); this branch keeps its names and structure.

Plan and work context

• Mission Control: DEV-6631 task 638 part A, plan; contract C3; parallel Machines Three kinds of Environment: the Folder's agent rule, the manual and the remaining surfaces (F28 addendum follow-up) #498/Apps → Trezor only where a vault is: the entry follows the vault core's answer (F36/F53 addendum, DEV-6612) #500 (task 637, released in v0.12.159).
• Worktree: HumanAndMachine-ai_GEN3/.worktrees/productionspace/LazurioPlatform/DEV-6631-environment-own-vault, branch agent/DEV-6631-environment-own-vault.
• Agent / thread: Claude Code (Opus 5.5), session b643d1c5-bc04-44a8-a2c5-d80707571628 (claude --resume b643d1c5-bc04-44a8-a2c5-d80707571628).
• Machine: the Admin's development workstation.

Status: ready for review

🤖 Generated with Claude Code

[agentrozjedemeai]

@immakermatty — changes requested on exact head 88c382d (#391).

Blocker — src/vault/organization.ts:142-174: A saved pendingKey does not prevent another POST when the profile temporarily omits the newly created organization. The code searches current confirmed memberships; on no match it generates a new key, overwrites the receipt and sends another create request. A delayed first request, a lagging profile, or a briefly unconfirmed membership can therefore create two organizations for one Environment, orphan the original, and violate the vault identity/idempotency contract. I reproduced this against the in-repo fake vault: let the first POST succeed but lose its answer, return a valid empty organization list from one subsequent profile request, then retry setup. The result was connected with 2 organizations; the recorded receipt was replaced. Please fail closed while an earlier receipt remains unresolved (or use a server-enforced idempotency/reconciliation mechanism), and add a test for this transient absence, not just a lost answer immediately visible in the profile.

Validation: 57 focused tests passed, 1 platform-specific test skipped locally; public guard passed. Green CI on this head. I found no client Organization or person named in the added source/docs; references to HumanAndMachine-ai/Machines and prototypes-lazurio are provider/source links. Schema re-pin to Machines #500 merge remains a declared pre-merge gate. No merge performed.

[immakermatty]

Re the blocker in the review of 88c382d: a saved pendingKey did not stop another create when the profile briefly omitted the new organization. Confirmed and fixed in 3425e71.

• An unresolved receipt fails closed. While a creation's receipt is unresolved, no setup sends another POST /api/organizations. Each run looks for the organization that carries the recorded public key among the account's memberships of any status (/api/accounts/profile, then GET /api/organizations/<id>/public-key). A membership whose key the vault refuses to show (4xx) is skipped. Any other failure ends the run with the receipt kept.
• Matches and the new state. A match is recorded once its membership is confirmed. Until then, and while nothing matches, the setup reports the new state creating. The local status says the same, the Launchpad's start sets it up again, and the row reads "Trezor se zakládá" with "Zkusit znovu".
• The bound. The receipt now carries its time (pendingSince, required with the key in toISOString form). Only a receipt older than 15 minutes (receiptBoundMs; a request times out at 30 s) that still matches nothing is taken for a creation that never happened. It is discarded, journaled as receipt-expired (no key, no id), and the vault is created once.
• Refused creations. A creation the vault refuses with its answer (4xx but 429) created nothing and discards its receipt at once, so organization-refused still recovers on the next run. No answer, or a 5xx, keeps the receipt.
• Tests (tests/vault-flow.test.ts):
  • Your reproduction: the POST succeeds with its answer lost, then one profile with an empty organization list, then a retry. Result: creating, one organization, one POST, receipt unchanged. The next setup finds it: connected, with that one organization and the receipt cleared.
  • A receipt that matches nothing (the POST never reached the vault) stays creating at 1 and 14 minutes, with no POST. At 15 minutes it makes exactly one organization, with receipt-expired journaled.
  • The record's form is in tests/vault-store.test.ts; the row's creating state is in tests/vault-view.test.ts.
  • Browser: a creation that never reached the vault reads "Trezor se zakládá" with "Zkusit znovu", and a retry stays there without a second creation.
• F52 point 3 now states the rule (see also docs/environment-tools.md).

bun run check on 3425e71: 2623 pass, 0 fail. CI on it is green; its first attempt failed one test in tests/launchpad-hosted.test.ts, untouched here: the page's boot document, which waits at most 500 ms, was missing from one of two page loads. The re-run passed, and the flake is filed as #405. The branch is not rebased onto the newer main, because follow-up PRs build on it; a trial merge with main (ad19a61) merges cleanly and passes tsc and the Folder and vault tests.

Ready for another look at 3425e71.

[agentrozjedemeai]

@immakermatty — APPROVED on exact head 3425e71. The earlier orphaned-second-organization reproduction now remains creating through a temporarily empty profile, keeps the same receipt, sends only one POST, and subsequently connects to the original organization. A genuinely unmatched receipt waits through 1 and 14 minutes and creates once at the 15-minute bound; the bound’s residual delayed-visibility risk is stated in the PR. I inspected the receipt/membership/status/Launchpad paths and F52. Local isolated-checkout validation: 29 focused tests passed, plus 15 Launchpad/CLI/handover tests passed (1 macOS skip); static check (Biome, TypeScript, public guard, proof build and smoke) passed. Head CI is green, with zero open review threads. git diff --check reports one nonblocking trailing blank line in docs/decisions.md. Before merge, re-pin the vendored handover schema to the merged Machines #500 commit and repeat exact-head checks/review gates; no merge performed by me.

[agentrozjedemeai]

@immakermatty — APPROVED on exact head 7eab155 (base a9f80c7). I rechecked the rebased changes against the previously approved 3425e71: the once-only creation receipt behavior is preserved; the Folder revision is 49 with its pinned digest, and the Bitwarden wording retains #328’s neutral form. F52 remains the module-generator decision and this vault decision and its links are F53. The vendored schema digest 76a058045be25b718caed8a04e533d67fa8666945bfa4fa0153d618bc4d78957 matches the released Machines v0.12.159 tag (8b66889bf4e00b111027f9b280423f4b9cdfcf4e) and Machines main; the pending provenance gate is cleared. Isolated checkout: 122 focused tests passed, 1 macOS-only skip; lint, TypeScript, public guard, proof build and smoke passed. Head CI is green; #413 and #414 track the reported unrelated flakes. Live pre-review gates: same head, mergeable, no open threads or competing review requests. The existing trailing blank line in docs/decisions.md remains nonblocking. No merge performed.