Discord surface: username allowlists don't resolve until a manual restart after the bot joins a guild

[juniperbevensee]

Symptom

Wire a Discord bot via surfaces/connect with DISCORD_ALLOWED_USERS=<username> before inviting it to a server → the adapter boots, logs Could not resolve usernames: <username>, and then silently ignores everyone. The operator's mental model is "connected = working"; the bot looks dead until someone manually restarts the container after the invite.

Hit on all six bots of the 2026-07-27/28 Cyborg.Garden rollout — each needed one manual docker restart after Authorize.

Cause

Username→ID resolution (_resolve_allowed_usernames in the hermes Discord adapter) runs once at on_ready against current guild members. A bot invited after boot never re-resolves.

Options

1. Real fix (adapter-side, hermes-agent-mt / upstream): re-run _resolve_allowed_usernames on on_guild_join (and arguably on a slow periodic retry while unresolved entries remain). Same fork-first pattern as the role-mention fix (hermes-agent-mt#121).
2. HSM-side workaround: a "re-resolve / restart" nudge in the harness UI when the Discord surface has unresolved username entries, or an automatic recreate triggered the first time the bot appears in a guild (HSM can poll /users/@me/guilds with the stored token post-connect).

Option 1 is where the bug lives; option 2 improves operator visibility either way (surfacing Could not resolve usernames in the surface status would have saved four debugging rounds).

Related: gardener seed memory/handoffs/2026-07/28-juniper-gardener-seed-garden-discord-agents.md (Task 3).

🤖 Generated with Claude Code

[juniperbevensee]

Additional evidence: resolution isn't just a boot-order problem. On h_cryptids, on_ready resolution succeeded at container start (Resolved 'juniperbevensee' -> 1519531373352849518, 23:05Z), yet a mention at 23:19Z was rejected with Unauthorized user: 1519531373352849518. Resolution updates the process env only — the .env file keeps the raw username, so any in-container gateway respawn (s6 supervision) or code path re-reading the file resurrects the unresolved entry. The adapter also auto-created a thread from the rejected message before the gateway auth gate fired, which makes the failure extra confusing for users (visible thread, no reply).

Workaround applied fleet-wide: store numeric user IDs in DISCORD_ALLOWED_USERS instead of usernames. Suggests a third option for the fix list: HSM resolves usernames to IDs at settings-write time (it has the bot token; one API call) so the .env file itself is always numeric — mirroring what expandSignalAllowlist already does for Signal.