[BUG] Preview dev server runs with no network egress and a different DENO_DIR than the user's shell

What's Wrong?

A dev server launched via the preview/launch.json mechanism runs with no network egress
and a different dependency cache root (implying a different HOME) than the user's login
shell. The resulting errors name the project's dependencies, so the developer debugs
their own code instead of the environment.

This cost significant misdirected effort in one session and prompted a serious (and
wrong) proposal to migrate the project to a different runtime.

Additionally, after .claude/launch.json was rewritten and verified on disk, a
subsequent start attempt reported failure from the PREVIOUS command — suggesting stale
launch configuration is cached and can be re-invoked after the file changes.

What Should Happen?

1. The preview environment's network and HOME/cache posture is documented, or aligned

with the user's shell.

1. A network failure inside preview surfaces that the subprocess has no egress, rather

than presenting as a project dependency error.

1. launch.json supports an explicit env map, so env need not be used as

runtimeExecutable to inject variables.

1. Cached launch configuration is invalidated when the file changes on disk.

Error Messages / Logs

Under preview:

Task server deno run --allow-net --allow-read ... deno/server.ts
Download https://deno.land/x/redis/mod.ts
error: Import 'https://deno.land/x/redis/mod.ts' failed.
0: error sending request for url (...): client error (Connect):
tcp connect error: No route to host (os error 65)

The same fetch from the login shell SUCCEEDED (downloaded redis and all jsr deps);
curl to the same URL returned HTTP 200.

Adding --cached-only to use the already-populated cache:

error: Specifier not found in cache: "https://deno.land/x/redis@v0.41.2/mod.ts",
--cached-only is specified.

The specifier IS present in the login shell's cache (~/Library/Caches/deno/remote).

Steps to Reproduce

1. Create a Deno project with a remote-URL dependency (e.g. https://deno.land/x/redis).
2. From a normal shell, run deno cache so the dependency is cached successfully.
3. Add .claude/launch.json with an entry running deno task server.
4. Start the preview server. Observe: "No route to host" for the dependency, despite

the same fetch working in the shell.

1. Add --cached-only to force offline use. Observe: "Specifier not found in cache",

despite the specifier being present in the shell's DENO_DIR.

1. Workaround required — note there is no documented env field:

"runtimeExecutable": "env",
"runtimeArgs": ["DENO_DIR=/Users/<user>/Library/Caches/deno",
"deno","run","--cached-only", ...]

Additional Information

The project's own startup failures (a wrong relative import, an orphaned code block, an
export-name mismatch) were separate, pre-existing, and fixed independently. All three
observations above persisted after those were resolved and are environment-scoped.

---

Environment

| | |
|---|---|
| Claude Code | 2.1.212 (Claude Code) |
| Platform | Claude API (Max subscription) |
| OS | macOS 27.0 (build 26A5425a, developer beta) |
| Hardware | Apple M2 Pro, arm64 |
| Terminal / Shell | Ghostty 1.3.1 / zsh (also reproduced in Terminal.app) |
| Model | Opus |
| Regression | No — not tested against a prior version |

Preflight: searched existing issues; single bug report; on latest version.