The latest commit get a 404 when connecting to deepseek api

[vaidhy]

I am on commit id ddefc45. All calls to deepseek API directly through api.deepseek.com returns back with a 404 when I start the harness with pnpm dsh web. npx @deepseek-ai/dsh web works

[PerryLink]

Short answer: I can't confirm the 404 cause without the actual request URL from your failing run — but there is a very likely mechanism: the API endpoint is resolved from the launch environment layers, and those layers legitimately differ between a source launch and npx. The endpoint math is where a 404 comes from, not the resolution-mode change (see below).

Grounded facts (HEAD = ddefc45, v0.1.6-alpha.2, the commit you named):

• The endpoint resolution chain: packages/llm/llm-deepseek/src/config.ts:292-293 — const baseURL = config.baseURL ?? environment?.get(BASE_URL_ENV)?.value ?? (protocol === 'messages' ? MESSAGES_BASE_URL : PUBLIC_BASE_URL). DEEPSEEK_BASE_URL from the launch snapshot beats the official default.
• Why source vs npx differ: config.ts:193-202 — the product CLI passes its launch environment snapshot, and "the product trusts the project it is launched in, so a checkout can point its own agent at the gateway that checkout is meant to use." A .env layer in the checkout root (the CLI loads layered env at apps/cli/src/bin.ts:39) can override the endpoint for pnpm dsh web while npx from elsewhere sees no such layer.
• Why that becomes a 404: the official Messages root is https://api.deepseek.com/anthropic (config.ts:106-107), and packages/llm/llm-deepseek/src/common/messages-api.ts:11-14 appends /v1 (unless the path already ends in /v1) and /messages on top. So a baseURL of https://api.deepseek.com (or a wrong gateway) with the default messages protocol builds https://api.deepseek.com/v1/messages → 404. This exact trap is documented in packages/llm/llm-deepseek/README.md:86: "An explicit https://api.deepseek.com override selects the Chat root."
• On the resolution-mode change: yes, alpha.2 flipped the source-launch default from link to runtime (commit 9ddef32; apps/cli/src/profile-boot.ts:263 at HEAD reads packaged ? 'runtime' : options.resolutionMode ?? 'runtime', alpha.1 had ?? 'link'). There is no flag or env override for it — dsh web just uses the built-in default (apps/cli/src/args.ts has no such option). But that mode changes how plugin packages resolve, not the URL construction above, so I'd treat it as a secondary suspect, not the answer.

First-round checklist, in order:

1. Confirm what actually runs: git status (uncommitted edits to profile-boot.ts would change your local default!) and git log -1 --format=%H in the checkout.
2. Capture the request URL: reproduce once and read the transport error carefully — it names the resolved endpoint. If it ends in /v1/messages on api.deepseek.com, that's the baseURL/protocol mismatch above.
3. Compare environments between the two launches: check DEEPSEEK_BASE_URL and any .env files in the checkout root, and run both launch styles from the same cwd with the same profile.
4. Check the profile config for an explicit baseURL on the llm-deepseek row (Web UI Models page or dsh --profile web --dump-config).

If you paste the log lines containing the failing request URL from the pnpm dsh web run, I'm happy to pin the exact cause.

[vaidhy]

It seems like that that is the error.. I had the URL set to https://api.deepseek.com and that was causing the issues.