#1178 Unclear whether SWAMP_API_KEY auth claims a device's banked "ghost" reputation, or only swamp auth login does

Summary

Automation/cron hosts commonly authenticate the swamp CLI via a SWAMP_API_KEY environment variable rather than the interactive swamp auth login OAuth flow, since that flow isn't practical on unattended machines. It's unclear whether activity authenticated this way is linked to the owning account the same way swamp auth login links it, or whether it accumulates against an unclaimed "ghost" device identity indefinitely.

Observation

We found a swamp-club.com "ghost" device page for a device with banked reputation/activity and no linked account. Its own copy states: "This is a device earning reputation in the Swamp with no operative attached. Its history is banked, not orphaned — the moment this device authenticates (swamp auth login), every point here folds into that account." That copy specifically names swamp auth login as the claiming trigger, not SWAMP_API_KEY-based auth.

This is consistent with how the CLI treats the two methods elsewhere — Lab issue submission (swamp issue bug/feature/etc.) explicitly requires swamp auth login; a valid SWAMP_API_KEY alone isn't documented as sufficient for that capability. That suggests API-key sessions may be a materially more limited tier than full login sessions, supporting the idea that API-key auth doesn't perform the same device-claim linking.

Why it matters

Automation hosts (cron, CI, homelab services) are exactly the machines most likely to accumulate long-running activity under SWAMP_API_KEY, and are also the machines where an interactive swamp auth login is least practical (headless, no browser). If API-key auth doesn't claim/link the device, there's no practical way to attribute that activity to the owning account on those hosts.

Ask

1. Confirm whether authenticating purely via SWAMP_API_KEY (no swamp auth login ever performed on that device) actually claims a pre-existing ghost device / links future activity to the account.
2. If not: consider making API-key auth perform the same claim/link behavior, since it's the intended mechanism for exactly the headless contexts where ghost devices are most likely to accumulate.
3. If it already claims correctly: the ghost page's own copy should probably mention SWAMP_API_KEY auth as an equivalent trigger, since it currently only mentions swamp auth login and leaves this ambiguous.

Environment

Multi-host homelab-style deployment sharing one swamp repo via a shared S3-compatible datastore — automation hosts authenticate via SWAMP_API_KEY exported in shell rc files for cron/model/workflow execution, primary dev machine uses swamp auth login.