Count explicit blank token overrides as account-local auth

If a named account explicitly clears a token field, this gate now suppresses default even though runtime resolution no longer falls back to the base credentials. For example, with channels.discord.token plus channels.discord.accounts.ops.token: "", extensions/discord/src/token.ts:39-52 returns source none for ops because hasAccountToken blocks base fallback, and extensions/discord/src/shared.ts:74-80 then treats ops as unconfigured. listAccountIds() therefore returns only ops, so gateway startup never starts the working base account anymore.

Useful? React with 👍 / 👎.

Valid edge case. The current predicate only checks for truthy per-account tokens, so an explicit blank override (token: "") is treated as "inherits base" rather than "no fallback". In practice, users would simply omit the field rather than blank it out, so this is a very niche scenario. Deferring to a follow-up.

Stop remapping raw IDs through normalizedToRaw in token checks

Looking up each configured id via normalizedToRaw.get(id) can alias distinct raw account keys during everyAccountHasOwnTokens evaluation and produce false positives. Fresh evidence: when no normalizeAccountId option is provided, listConfiguredAccountIds returns raw keys unchanged, so a config containing both A and a is valid here; this line remaps a to the first normalized match, so the token-override check can read the same account twice, incorrectly inject default, and start an extra base-credential runtime alongside an inheriting account.

Useful? React with 👍 / 👎.

Acknowledged. The concern is real in theory but requires a config with case-distinct raw keys that collapse under normalization (e.g. accounts: { A: {}, a: {} }) — a config that's already broken at the channel-routing level since account lookups are case-insensitive. Deferring to a follow-up if this surfaces in practice; the mainline path is correct.

Avoid aliasing distinct raw account keys in token checks

Using normalizedToRaw.get(id) ?? id here aliases case-distinct raw keys when no custom normalizer is provided (for example accounts: { A: {...}, a: {} }), so the everyAccountHasOwnTokens gate can read the same account twice and incorrectly inject default. Fresh evidence versus the prior thread: listConfiguredAccountIds() returns raw IDs unchanged when normalizeAccountId is not set, so both A and a do reach this remap path and can be conflated.

Useful? React with 👍 / 👎.

Acknowledged. The concern is real in theory but requires a config with case-distinct raw keys that collapse under normalization (e.g. accounts: { A: {}, a: {} }) — a config that's already broken at the channel-routing level since account lookups are case-insensitive. Deferring to a follow-up if this surfaces in practice; the mainline path is correct.

Avoid aliasing raw account keys in token-ownership checks

This remaps each configured id through normalizedToRaw, but when no custom normalizer is provided listConfiguredAccountIds returns raw keys unchanged, so distinct raw keys that normalize the same (e.g. "Router D" and "router-d") are conflated here. The ownership check can then read the wrong account config and incorrectly conclude all accounts have independent tokens, injecting default and starting an extra base-credential runtime alongside an inheriting account. Fresh evidence against the earlier rebuttal is that raw IDs do reach this remap path when options.normalizeAccountId is absent.

Useful? React with 👍 / 👎.

Acknowledged. The concern is real in theory but requires a config with case-distinct raw keys that collapse under normalization (e.g. accounts: { A: {}, a: {} }) — a config that's already broken at the channel-routing level since account lookups are case-insensitive. Deferring to a follow-up if this surfaces in practice; the mainline path is correct.

Stop aliasing raw ids through normalizedToRaw lookups

When no normalizeAccountId option is provided, listConfiguredAccountIds returns raw account keys, but this remap still routes each id through normalizedToRaw. With case-distinct keys like accounts: { A: { token: "own" }, a: {} }, id === "a" resolves to raw key "A", so everyAccountHasOwnTokens can read the same account twice and incorrectly inject default; startup then runs both a and default, which can duplicate base-credential runtimes (for example Discord/Slack inheriting base tokens). Fresh evidence after the earlier thread: production callers such as extensions/discord/src/accounts.ts:21 and extensions/slack/src/accounts.ts:29 call createAccountListHelpers without a normalizer, so this path is reachable.

Useful? React with 👍 / 👎.

Acknowledged. The concern is real in theory but requires a config with case-distinct raw keys that collapse under normalization (e.g. accounts: { A: {}, a: {} }) — a config that's already broken at the channel-routing level since account lookups are case-insensitive. Deferring to a follow-up if this surfaces in practice; the mainline path is correct.