[BUG]: OpenRouter API configured but router validation fails in npx mode

[idevilofhell]

Describe the bug

I have configured OpenRouter API (OpenAI-compatible endpoint) during setup, but the workflow fails during execution with a custom endpoint validation error.

Even though the API key and base URL are correctly set, Shannon fails to validate the router endpoint.

This issue occurs specifically when running in npx mode with the router enabled.

Steps to reproduce

Run Shannon using npx:
npx @keygraph/shannon start -u http://127.0.0.1:3000 -r "" --router

3. Wait for containers (temporal + router) to start

4. Open workflow UI

5. Observe failure at runPreflightValidation stage

Expected behaviour

Shannon should successfully validate the OpenRouter endpoint and proceed with the workflow execution.

Actual behaviour

Workflow fails with the following error:

Custom endpoint (http://shannon-router:3456) validation failed unexpectedly.
Check your credentials in .env

Failure occurs during runPreflightValidation.

Pre-submission checklist (required)

• I have searched the existing open issues and confirmed this bug has not already been reported.
• I am running the latest released version of shannon.

If applicable

• I have included relevant error messages, stack traces, or failure details.
• I have checked the workspaces folder for logs and pasted the relevant errors.
• I have inspected the failed Temporal workflow run and included the failure reason.
• I have included clear steps to reproduce the issue.
• I have redacted any sensitive information (tokens, URLs, repo names).

Debugging details

No response

Screenshots

CLI mode

npx (@keygraph/shannon)

Provider

Router - OpenRouter

Full command with all flags used (with redactions)

npx @keygraph/shannon start -u http://127.0.0.1:3000 -r "E:\Company Dedicated\juice-shop" --router

OS (with version)

windows 10

Node.js version ('node -v')

Node.js: v20.x

Docker version ('docker -v')

Docker version 29.3.1, build c2be9cc

Additional context

No response

[ezl-keygraph]

@idevilofhell

Thanks for reporting this. Could you share the following details to help us reproduce the issue on our side

1. Which option did you choose: Custom Base URL or Router?

2. If you chose Custom Base URL, which proxy or gateway were you trying to configure? It should be Anthropic-compatible.

3. If you chose Router, which provider did you select: OpenAI or OpenRouter?

4. Which model did you choose from that provider?

Provider	Model
OpenAI	GPT-5.2
OpenAI	GPT-5 mini
OpenRouter	Google Gemini 3 Flash Preview

Router mode is experimental. You can take a look into README.md

[Karen86Tonoyan]

czy sprawdzaliscie wasze api open ruthera jest aktywne poprawnmie skonfigurwane.W pliku .n mozliwe ze problem lezy od strony prowidera zmien go na google gdyz najlej sie sprawdza

…

On Fri, Apr 3, 2026 at 9:54 PM ezl-keygraph ***@***.***> wrote: *ezl-keygraph* left a comment (KeygraphHQ/shannon#272) <#272 (comment)> @idevilofhell <https://github.com/idevilofhell> Thanks for reporting this. Could you share the following details to help us reproduce the issue on our side 1. Which option did you choose: Custom Base URL or Router? Screenshot.2026-04-04.at.1.12.57.AM.png (view on web) <https://github.com/user-attachments/assets/97ccd81c-23ef-41a8-b63a-99bb1617fe54> 2. If you chose Custom Base URL, which proxy or gateway were you trying to configure? It should be Anthropic-compatible. 3. If you chose Router, which provider did you select: OpenAI or OpenRouter? Screenshot.2026-04-04.at.1.15.44.AM.png (view on web) <https://github.com/user-attachments/assets/58e3854c-e183-4c99-a7a9-8f16be94b922> 4. Which model did you choose from that provider? Provider Model OpenAI GPT-5.2 OpenAI GPT-5 mini OpenRouter Google Gemini 3 Flash Preview — Reply to this email directly, view it on GitHub <#272?email_source=notifications&email_token=BUHB4EYPRCC74UINLGGSGWL4UAJHHA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIMJYGQ4TOMBVGEYKM4TFMFZW63VKON2WE43DOJUWEZLEUVSXMZLOOSWGM33PORSXEX3DNRUWG2Y#issuecomment-4184970510>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BUHB4E2PJPRCCYK7BRIVWPD4UAJHHAVCNFSM6AAAAACXLT6X5CVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DCOBUHE3TANJRGA> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[Karen86Tonoyan]

This looks more like a router validation bug in "npx" mode than a simple user misconfiguration.

The key clue is the failure during "runPreflightValidation" with:
"Custom endpoint (http://shannon-router:3456) validation failed unexpectedly."

A few concrete things to verify on your side:

1. Is "--router" in "npx" mode taking the Router path but still applying Custom Base URL validation logic?
2. Is "shannon-router:3456" reachable from the validation step container/process at the moment validation runs?
3. Is the validation assuming Anthropic-compatible behavior even when Router + OpenRouter is selected?
4. Can you share the exact supported matrix for "Router" mode in "npx" (provider + model), and whether OpenRouter is expected to pass preflight here consistently?

Since Router mode is marked experimental, this may be a sequencing or validation-path issue rather than a credentials problem in ".env".

It would help to log:

• which config branch is selected at runtime ("Custom Base URL" vs "Router")
• the exact endpoint being validated
• the provider/model pair resolved before preflight
• whether the router service is already healthy when validation starts

That should make it much easier to tell whether this is env/config related or an actual bug in the router validation flow.