Summary
OPENROUTER_DEBUG is parsed with z.coerce.boolean(), which is JavaScript Boolean(value) — true for any non-empty string. So OPENROUTER_DEBUG=false (and 0, off, no) all coerce to true and enable debug logging, the opposite of what an operator setting it to false intends. Once enabled, the debug logger prints all request/response headers (including Authorization and cookie/set-cookie) and full JSON bodies, with no redaction.
That debug logging reveals secrets is already documented and intended — the README says: "Beware that debug logging will reveal secrets, like API tokens in headers… use this feature only during local development and not in production." So this report is not about the logging content; it is about the env-var coercion. The hazard is the footgun: an operator who sets OPENROUTER_DEBUG=false to turn logging off actually turns it on, and the documented secret exposure then happens against their intent.
Affected code
src/lib/env.ts (on main, d26f835):
OPENROUTER_DEBUG: z.coerce.boolean().optional(), // Boolean("false") === trueThe value then gates the logger in src/lib/sdks.ts: if (!this.#logger && env().OPENROUTER_DEBUG) { this.#logger = console; } — so OPENROUTER_DEBUG=false activates the (documented, secret-revealing) console logger.
Impact
The surprise is concentrated exactly where it does the most harm: an operator who explicitly sets OPENROUTER_DEBUG=false to keep secrets out of logs gets the opposite, and the documented header/body exposure happens in production where it was meant to be off.
How to reproduce / confirm
- Set
OPENROUTER_DEBUG=false and construct the client.
- Make a request — debug logging is active (the
Authorization header and request/response bodies are printed), despite the env var being false.
Suggested fix
Either is fine; the maintainers' call:
- Code: parse
OPENROUTER_DEBUG so false, 0, off, no, and empty resolve to false (instead of bare z.coerce.boolean), so disabling works as written; or
- Docs: document that
OPENROUTER_DEBUG is enabled by any non-empty value (use OPENROUTER_DEBUG=1/unset it to disable), since that is the current behavior.
Summary
OPENROUTER_DEBUGis parsed withz.coerce.boolean(), which is JavaScriptBoolean(value)—truefor any non-empty string. SoOPENROUTER_DEBUG=false(and0,off,no) all coerce totrueand enable debug logging, the opposite of what an operator setting it tofalseintends. Once enabled, the debug logger prints all request/response headers (includingAuthorizationandcookie/set-cookie) and full JSON bodies, with no redaction.That debug logging reveals secrets is already documented and intended — the README says: "Beware that debug logging will reveal secrets, like API tokens in headers… use this feature only during local development and not in production." So this report is not about the logging content; it is about the env-var coercion. The hazard is the footgun: an operator who sets
OPENROUTER_DEBUG=falseto turn logging off actually turns it on, and the documented secret exposure then happens against their intent.Affected code
src/lib/env.ts(onmain,d26f835):The value then gates the logger in
src/lib/sdks.ts:if (!this.#logger && env().OPENROUTER_DEBUG) { this.#logger = console; }— soOPENROUTER_DEBUG=falseactivates the (documented, secret-revealing) console logger.Impact
The surprise is concentrated exactly where it does the most harm: an operator who explicitly sets
OPENROUTER_DEBUG=falseto keep secrets out of logs gets the opposite, and the documented header/body exposure happens in production where it was meant to be off.How to reproduce / confirm
OPENROUTER_DEBUG=falseand construct the client.Authorizationheader and request/response bodies are printed), despite the env var beingfalse.Suggested fix
Either is fine; the maintainers' call:
OPENROUTER_DEBUGsofalse,0,off,no, and empty resolve tofalse(instead of barez.coerce.boolean), so disabling works as written; orOPENROUTER_DEBUGis enabled by any non-empty value (useOPENROUTER_DEBUG=1/unset it to disable), since that is the current behavior.