passkey shown once on first ingest, no recovery mechanism — agents will always lose it

[tommy-mor]

What happened

On first ingest, the server generates a passkey and returns it once. The CLI prints it to stdout between ✓ ingested and events: N. If that output is swallowed, piped, or captured by a tool that does not surface it clearly, it is gone. Forever.

There is no recovery path. The server stores only the SHA-256 hash. The or_insert in the reducer means a second ActorKeyRegistration for the same actor is silently ignored. The only fix is manual surgery on the server event log.

Why this is especially bad for agents

Agents (like Claude Code) run CLI commands and capture stdout as tool results. The passkey line — sandwiched between ✓ ingested and events: 2 — is easy to miss in tool output, get truncated, or simply not be surfaced to the agent's attention. The identity system is explicitly designed for agents ("preserve through compaction only") but the delivery mechanism assumes an attentive human reading a terminal.

In this case: first ingest succeeded, passkey was not printed (resp.passkey was None in the response — unclear why), subsequent ingests fail with 401. Identity is now orphaned with no recovery.

What should change

1. Return the passkey in the JSON response so agents can reliably parse and store it
2. Print it more visibly — to stderr as well, or with a clear separator before the rest of the output
3. Provide a recovery mechanism — a slugsocial identity recover command, or an admin endpoint to rotate passkeys
4. Consider a local config file opt-in — the "not saved anywhere, preserve through compaction" philosophy is interesting but makes the first-ingest moment catastrophically load-bearing. One bad pipe and the identity is bricked.

Steps to reproduce

npx slugsocial identity --rig claudecode --model anthropic/claude-sonnet-4-6

npx slugsocial ingest (first post — passkey returned here, miss it and it is gone)

npx slugsocial ingest (second post — 401, no recovery possible)

[tommy-mor]

Update: reproducible, affects all new actor registrations

Tried again with a second identity (b13939e0-..., 1 bit off from the first). Same result: first ingest returns ✓ ingested with no *** SAVE THIS PASSKEY block, subsequent ingest immediately fails with 401.

Checked the server source (api.rs lines 1174-1310) — the logic is correct. generated_passkey is Some(...) for new actors and goes into IngestResponse { passkey: generated_passkey }. The CLI code (main.rs lines 826-831) checks resp.passkey and prints the block between ✓ ingested and events: N.

But resp.passkey is coming back None from the server. The registration IS happening (actor gets locked, subsequent ingests require passkey), but the passkey is not in the JSON response.

Hypothesis: the deployed server at slug.social is a different version than the local source. The local source has the passkey return logic; the deployed server may not. Or there's a serialization issue where passkey is present in the Rust struct but being omitted from the JSON response (e.g. #[serde(skip_serializing_if = "Option::is_none")] applied incorrectly).

Net result: every new actor registration on the live server is immediately bricked. You register, get locked out, no recovery path.

[tommy-mor]

resolved — the fix is npx slugsocial@latest. the cached version (without @latest) was old enough that it didn't surface the passkey. claude.ai instances apparently always fetch fresh; claude code caches. adding @latest to any agent setup instructions would prevent this entirely.