From 52612b516b8a61f4c1fe6ffb797b67f2f5bea18b Mon Sep 17 00:00:00 2001 From: Thales Maciel Date: Wed, 22 Apr 2026 18:06:52 -0300 Subject: [PATCH] README: describe the SSH-key migration as a VM restart, not workspace sync MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The migration note said existing VMs needed a "fresh workspace sync" to pick up a new host SSH key fingerprint. That's wrong: workspace.prepare (vm workspace prepare) touches the git checkout, not authorized_keys. The authorized_keys rewrite happens on the vm start path — specifically in workDiskCapability.PrepareHost calling WorkspaceService.ensureAuthorizedKeyOnWorkDisk, which runs during start, not during an explicit workspace sync. Rewrite the note to name the actual recovery action: stop-and-start (or vm restart). Leave the --rm caveat — those flows always boot fresh and don't carry the problem. Co-Authored-By: Claude Opus 4.7 (1M context) --- README.md | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/README.md b/README.md index 215e2d6..cf6a1bb 100644 --- a/README.md +++ b/README.md @@ -165,9 +165,12 @@ Full key list in `internal/config/config.go`. > hardcoded in `config.toml`, either keep it (banger preserves the > directory when `ssh_key_path` points inside it) or unset the key > and banger will manage the new default for you. The first time the -> daemon starts against the new default, guest VMs need a fresh -> workspace sync (`banger vm stop && start`, or `--rm` flows are -> unaffected) so their `authorized_keys` pick up the new fingerprint. +> daemon starts against a new key, any already-running guest VMs +> still carry the previous fingerprint in their `authorized_keys`. +> Stop-and-start each VM (`banger vm stop && banger vm start +> `, or `vm restart`) to let the start-path reprovision the +> work disk with the new key. Fresh VMs and `--rm` flows are +> unaffected. ### `vm_defaults` — sizing for new VMs