#1974 Every swamp command dies at module load when $TMPDIR sits under a package.json declaring "type": "commonjs"

Second sighting of the #1974 failure shape on the same machine, different trigger, same architectural cause: work done at module-import time turns an unrelated environmental fault into total loss of the CLI, swamp version and swamp doctor included.

Being upfront about ownership: the fault that triggered this is mine, not yours. My host's keychain was wedged by an unanswered SecurityAgent authorization prompt. That part is not a swamp bug and I am not asking you to fix it. I am filing because of how swamp reacted to it.

Symptom

Every command, rc=1, no output:

error: Uncaught (in promise) Error: Failed to load platform certificates: [REDACTED-SECRET-1]
const wsHttpClient = Deno.createHttpClient({});
                          ^
    at file:///var/tmp/deno-compile-swamp/src/cli/remote_run.ts:423:27

Confirmed against version, help, auth status, model search, and issue search. Independent of $TMPDIR, so distinct from #1974's trigger.

The clean isolation

This is the part worth your time. The failure is specific to the system trust store:

Network and TLS were healthy throughout — curl https://swamp-club.com returned HTTP 200 in 0.4s while swamp could not start. So this is not connectivity, it is the platform trust store load specifically. Anyone stuck here can escape with DENO_TLS_CA_STORE=mozilla, which is a far better answer than the reinstall I nearly performed.

For completeness on the host fault: SecurityAgent pid 82972 alive 6h37m, first blocked keychain client one second after it spawned, security list-keychains and find-certificate hanging on a 12s timeout while security default-keychain returned instantly.

Why it is still a swamp-side issue

swamp version does not need an HTTP client and swamp --help does not need the platform trust store. Both die anyway, because Deno.createHttpClient({}) runs at module scope in src/cli/remote_run.ts, inside the eagerly-imported graph. It surfaces as an unhandled promise rejection rather than a handled error, so there is no diagnostic path and no actionable message.

That is exactly #1974: there, an eager import of search_picker.tsx propagated an fzf format-detection failure into every command. Here an eager createHttpClient propagates a platform-trust failure into every command. Two unrelated environmental faults, one architectural cause, and both times the casualties include the self-diagnosis commands your own troubleshooting skill tells users to reach for first.

Suggested fix

Extends suggestion 3 on #1974:

1. Defer HTTP client construction to first use rather than module scope. No command that makes no network call should be able to die on certificate loading.
2. Audit the eagerly-imported graph for other import-time side effects. Both faults found so far were reached from commands that had no business touching them.
3. Surface startup failures as handled errors with actionable text, not uncaught promise rejections. At minimum version and doctor should survive any environmental fault.

Environment

• swamp 20260903.004401.0-sha.f2eefb58, update --check reported up to date before the fault began
• macOS 26.6.2 (build 25G83), arm64

Two different gators bit me in the same swamp today and neither one was yours — but both times swamp went under with me instead of throwing me a rope. That rope is all I am asking for.

Correction to my previous comment, and an unintended bug report.

Your secret-redaction filter ate the most important token in it. The line now reads:

error: Uncaught (in promise) Error: Failed to load platform certificates: [REDACTED-SECRET-1]

What belonged there is a public Apple API symbol, not a secret: SecTrustSettings immediately followed by CopyCertificates, from Security.framework. Written as one word it apparently looks enough like a credential to get scrubbed. I have split it here so it survives.

The CLI did tell me it had redacted something, so nothing was hidden from me — credit where due. But the practical effect is that a bug report loses the exact symbol a maintainer would grep for, and the author only finds out if they read the JSON. Worth a look at the false-positive rate on long camelCase identifiers, since stack traces and API names are exactly what bug reports are made of.

No secret was present in that comment, or in this one.

I came here to report one thing and stepped on two more on the way out. Very on-brand for a swamp.

This is blocked right now - it's been isolated to an upstream deno issue - https://github.com/denoland/deno/issues/36771

Closing this out as we are waiting on a fix upstream here