fix: update start-cli for signed StartOS authentication

[helix-nine]

Summary

• replace the cookie-auth start-cli 0.4.0-alpha.20 with signing-key start-cli 1.1.0
• point the download at the product-scoped start-cli/v… release and rename the build arg STARTOS_VERSION → START_CLI_VERSION
• make Revoke StartOS Access un-enroll the key server-side, and clean up the pre-1.1.0 credential names
• document the start-cli pin in UPDATING.md, which never covered it
• bump to 2026.7.1:5

Root cause

The image baked start-cli from start-os/v0.4.0-alpha.20, which sends an unsigned password request and expects a cookie back. Signature auth replaced that server-side in start-os/v0.4.0, so a supported host rejects the request before it ever validates the password — Login to StartOS could not succeed on any host able to install this package.

The old URL was …/Start9Labs/start-os/releases/download/v${STARTOS_VERSION}/…, whose tag segment is hardcoded as v + the version. The 1.x releases live on product-scoped tags (start-cli/v1.1.0), which that shape cannot express — so the pin was stuck on the last legacy-tagged build. The new URL encodes the slash as start-cli%2Fv${START_CLI_VERSION}.

Same defect and same fix as Start9-Community/hermes-agent-startos#12.

Revoke was leaving keys enrolled

auth login enrolls the public key in the server's key store — the same store auth session list reads. Deleting the local file revoked access (no secret, no signable request) but stranded an unnamed entry on the server, and every login/revoke cycle stranded another. The action now runs auth logout first, which un-enrolls it.

The logout is best-effort and wrapped: an unreachable host, a missing CA, or an already-revoked key must never block the local delete, since that delete is what actually revokes access.

Deliberately not changed

Unlike hermes-agent, this package does not need a login-time chown. Login already runs as node, and /data is chowned to node:node by the boot oneshot on every start; login while stopped therefore finds a node-owned .startos from the last boot. Before the first start there is no .startos at all, and the host guard in loginToOs fails with a clear message rather than an EACCES. Flagging it because the two packages otherwise mirror each other here.

Upstream

No bump due. openclaw latest stable is v2026.7.1 (already pinned) — v2026.7.2-beta.* are prereleases, which UPDATING.md says to skip. gh latest is v2.96.0, already pinned.

Verification

• npm run check (tsc --noEmit)
• npx prettier --check on the touched files
• start-cli/v1.1.0 publishes both start-cli_x86_64-linux and start-cli_aarch64-linux
• the %2F download URL resolves (HTTP 200) and the same URL built successfully in the sibling hermes-agent image
• no STARTOS_VERSION references remain anywhere in the repo
• not built or installed on a StartOS box — see test plan

Test plan

1. make x86 install against a StartOS 0.4.0+ box. Confirm the image build's start-cli download step succeeds (it is the step that 404'd under the old URL shape).
2. Start the service. The Login to StartOS task should appear, since check-login finds no enrolled key.
3. Run Login to StartOS with the correct master password. Expect success rather than an UNAUTHORIZED unsigned-request error.
4. On the host, confirm /media/startos/data/package-data/volumes/openclaw/data/main/.startos/id.key.pem exists as node-owned, mode 0640.
5. start-cli auth session list on the host — a platforms: ["cli"] entry should now be present.
6. Run Revoke StartOS Access. Confirm id.key.pem is gone and the session entry from step 5 has disappeared.
7. Run Revoke StartOS Access again with no key present. It should still report success rather than erroring.

🤖 Generated with Claude Code