fix(gateway): skip token platforms with no credential on secondary profiles

[manny3]

What does this PR do?

Fixes the mirror case of #64674, which was left open.

#64674 / #65525 fixed the default profile connecting a token platform whose bot credential lived only in a secondary profile's .env, and taught the reconnect watcher to drop such queued configs. The opposite direction still fails: a secondary profile can have discord/telegram enabled — the plugin registry auto-enables them for any profile that lists those plugins — while the credential lives only in the default profile's .env.

That is the normal shape for a profile used purely as a gateway.profile_routes target. Per gateway/profile_routing.py, such a profile supplies the model/tools/memory/persona, and inbound arrives on the default profile's single connection — it is not a second bot and has no reason to hold a token. But _start_one_profile_adapters builds an adapter for it anyway, so every gateway start logs:

ERROR   [Discord] No bot token configured
WARNING ✗ discord failed to connect (profile: mentor)
ERROR   [Telegram] No bot token configured
WARNING ✗ telegram failed to connect (profile: mentor)

for connections that can never succeed. _platform_has_bot_credential() already exists for exactly this decision and is applied at the two other sites that need it (run.py:7758 primary startup, run.py:8740 reconnect watcher). This adds the missing third call site so all three agree.

Reusing the helper rather than writing a fresh check keeps its established semantics: platforms outside PLATFORM_TOKEN_ENV_NAMES are never skipped (Signal session paths, port-binding HTTP adapters), and api_key counts as a credential for adapters that take it as primary.

Interaction with #68746 — please read before merging

#68746 is open and modifies _platform_has_bot_credential() itself, adding a live raw-os.environ fallback for the reconnect path. That fallback is correct there but wrong at this new call site: the process env holds the default profile's tokens, and _profile_runtime_scope deliberately does not mutate os.environ (see its docstring). So if #68746 lands as written, this guard would see the default profile's DISCORD_BOT_TOKEN, decide the routes-only profile "has" a credential, and start connecting the default profile's bot on every secondary profile again — silently reintroducing this bug.

Whichever of the two merges second should make the env re-check resolve through the profile's secret scope (get_secret) rather than raw os.environ, or skip the fallback for the secondary-profile call. There is a code comment at the call site flagging this so it is not lost. Happy to rebase onto #68746 and do that reconciliation here if you'd prefer it in one PR.

Related Issue

Mirror case of #64674 (fixed for the primary path by #65525). No separate issue filed — say the word and I'll open one.

Fixes #

Type of Change

• 🐛 Bug fix (non-breaking change that fixes an issue)
• ✨ New feature (non-breaking change that adds functionality)
• 🔒 Security fix
• 📝 Documentation update
• ✅ Tests (adding or improving test coverage)
• ♻️ Refactor (no behavior change)
• 🎯 New skill (bundled or hub)

Changes Made

• gateway/run.py — in _start_one_profile_adapters(), skip a platform when _platform_has_bot_credential() reports no credential for that profile's config, logging at INFO which profile was skipped and why instead of failing an impossible connection. Placed after the existing Platform.RELAY skip.
• tests/gateway/test_secondary_profile_missing_token_skip.py — new suite (4 cases): missing token (both None and "") is skipped; a profile with its own token still connects; api_key alone counts as a credential; a non-token platform (SIGNAL) is never skipped.

The tests drive the real GatewayRunner._start_one_profile_adapters rather than re-implementing its loop body, so the guard cannot regress silently. The runner stub is deliberately complete enough that removing the guard fails on the meaningful created == [] assertion — my first version died early on an incidental AttributeError instead, which would have made the suite near-worthless as a regression guard.

How to Test

Reproduce (this is the live configuration the bug was found on):

1. A default profile with DISCORD_BOT_TOKEN in ~/.hermes/.env, and gateway.multiplex_profiles: true with a profile_routes entry pointing a channel at a secondary profile:

   gateway:
     multiplex_profiles: true
     profile_routes:
       - name: mentor-council
         platform: discord
         guild_id: "<guild>"
         chat_id: "<channel>"
         profile: mentor

2. profiles/mentor/.env with no messaging tokens (correct: one bot token cannot be polled twice, and the same-token detector at run.py:9592 already refuses that).
3. Start the gateway → on main every start logs No bot token configured + ✗ discord failed to connect (profile: mentor) for both discord and telegram.

Verify the fix — with this branch, the same start instead logs:

INFO Skipping discord on profile 'mentor': no bot credential in this profile's secrets.
     Inbound for this profile arrives on the default profile's connection via gateway.profile_routes.
INFO Skipping telegram on profile 'mentor': ...
INFO Gateway running with 2 platform(s)

Confirmed live on the setup above: zero failed to connect lines, both default-profile platforms still connect, and routing is unaffected — match_profile_route() still resolves the routed channel to mentor and other channels to the default profile.

Automated:

pytest tests/gateway/test_secondary_profile_missing_token_skip.py -q          # 4 passed
pytest tests/gateway/test_64674_multiplex_primary_token_scope.py -q           # 8 passed (sibling suite)
pytest tests/gateway/ -q -k "multiplex or profile"                            # 245 passed, 2 skipped

Checklist

Code

• I've read the Contributing Guide
• My commit messages follow Conventional Commits (fix(scope):, feat(scope):, etc.)
• I searched for existing PRs to make sure this isn't a duplicate — nearest are fix(gateway): multiplex primary bot tokens without empty reconnect loops (#64674) #64986/fix(gateway): multiplex primary gateways resolve bot tokens through profile secret scope (#64986 salvage) #65525 (the primary-path half of [Bug]: Telegram adapter fails to start on default-profile gateway when multiplex_profiles: true and bot token lives in a secondary profile .env #64674) and fix(gateway): re-check env for late-resolved bot token on reconnect #68746 (modifies the same helper; interaction documented above)
• My PR contains only changes related to this fix/feature (no unrelated commits)
• I've run pytest tests/ -q and all tests pass — see note below
• I've added tests for my changes (required for bug fixes, strongly encouraged for features)
• I've tested on my platform: macOS 12 (Darwin 21.6.0), Python 3.11

On the full-suite checkbox, left unchecked deliberately. pytest tests/gateway/ -q gives 9927 passed / 14 failed on my machine. I verified none of the 14 are mine: re-running exactly those 14 with and without this patch gives an identical 5 failed / 9 passed both ways. The 9 pass in isolation and only fail in the full run (pre-existing ordering dependence); the remaining 5 are environmental on macOS (test_systemd_notify needs systemd, plus test_shutdown_forensics subprocess spawn, test_background_command media routing, test_busy_session_ack). Happy to paste the full output.

Documentation & Housekeeping

• I've updated relevant documentation (README, docs/, docstrings) — or N/A — N/A: no user-facing config or API surface changes; the reasoning lives in a code comment at the call site
• I've updated cli-config.yaml.example if I added/changed config keys — or N/A — N/A: no new config keys
• I've updated CONTRIBUTING.md or AGENTS.md if I changed architecture or workflows — or N/A — N/A
• I've considered cross-platform impact (Windows, macOS) per the compatibility guide — or N/A — pure control-flow guard on an existing pure-Python predicate; no platform-specific paths
• I've updated tool descriptions/schemas if I changed tool behavior — or N/A — N/A

Screenshots / Logs

Before (on main, every gateway start):

2026-07-26 23:27:24 INFO  gateway.run: ✓ discord connected
2026-07-26 23:27:24 ERROR [Discord] No bot token configured
2026-07-26 23:27:24 WARN  gateway.run: ✗ discord failed to connect (profile: mentor)
2026-07-26 23:27:24 ERROR [Telegram] No bot token configured
2026-07-26 23:27:24 WARN  gateway.run: ✗ telegram failed to connect (profile: mentor)
2026-07-26 23:27:24 INFO  gateway.run: Gateway running with 2 platform(s)

After (this branch, same config, nothing else changed):

2026-07-27 00:06:36 INFO gateway.run: ✓ discord connected
2026-07-27 00:06:36 INFO gateway.run: Skipping discord on profile 'mentor': no bot credential in this
                                     profile's secrets. Inbound for this profile arrives on the default
                                     profile's connection via gateway.profile_routes.
2026-07-27 00:06:36 INFO gateway.run: Skipping telegram on profile 'mentor': ...
2026-07-27 00:06:36 INFO gateway.run: Gateway running with 2 platform(s)

🤖 Generated with Claude Code

[alt-glitch]

This was generated by AI during triage.

Related to #68746: this secondary-profile call site must decide from the profile-scoped config, while #68746 changes the shared helper to fall back to process environment. Please resolve that contract before merging both.

[teknium1]

Thanks for the focused multiplexing fix. The premise still holds on current main: _start_one_profile_adapters loads the secondary profile under its secret scope (gateway/run.py:12520-12521) but then creates every enabled adapter (gateway/run.py:12550-12563) and logs a failed connection when it cannot connect (gateway/run.py:12624-12638).

The proposed config-only predicate fits the existing isolation contract: _profile_runtime_scope installs a per-profile secret mapping without modifying os.environ (gateway/run.py:1778-1809), and PLATFORM_TOKEN_ENV_NAMES explicitly distinguishes token platforms from session- and listener-authenticated platforms (gateway/config.py:577-590). The added tests cover absent/blank credentials, own credentials, API-key credentials, non-token platforms, and process-environment isolation.

GitHub currently reports the PR as mergeable, despite it being behind current main.

Automated hermes-sweeper review.

[teknium1]

Thanks for this PR. Merged via #101244 (0fd9218) on current main — routed multiplex profiles stop leaking .env into os.environ or borrowing default creds.

#101244 won as the consolidated fix because it covers the whole multiplex-profile bug class in one change (with tests) rather than the single symptom addressed here; this PR is superseded by it.
You are credited via Co-authored-by / in the PR body of #101244 as noted there.

If anything from your original change is still missing on main >= 0fd9218, please open a fresh PR/issue against main and tag it. Thanks again.