Skip to content

Fresh installs of t3@0.0.40 hang in an npm ERESOLVE loop since @effect/platform-node-shared@4.0.0-rc.114 was published #11208

Closed
Closed
Fresh installs of t3@0.0.40 hang in an npm ERESOLVE loop since @effect/platform-node-shared@4.0.0-rc.114 was published#11208
Labels
bugSomething is broken or behaving incorrectly.plannedvia-triageFiled through npx t3 triage

Description

@idoabra
idoabra
opened on Sep 11, 2026

What happened

I couldn't update my Linux background service from 0.0.39 to 0.0.40. Both npx t3@latest service update and npx t3@0.0.40 service update print this npm warning over and over and never finish:

npm warn ERESOLVE overriding peer dependency
npm warn While resolving: @effect/platform-node-shared@4.0.0-rc.114
npm warn Found: peer effect@"^4.0.0-rc.114" from the root project
npm warn
npm warn Could not resolve dependency:
npm warn peer effect@"^4.0.0-rc.114" from the root project

Diagnosis

A fresh npm install of t3@0.0.40 can't resolve its dependency tree right now. Nothing on the machine causes it. The chain:

  1. t3@0.0.40 depends on @effect/platform-node@4.0.0-beta.103 (exact).
  2. @effect/platform-node@4.0.0-beta.103 depends on @effect/platform-node-shared@^4.0.0-beta.103. A caret on a prerelease matches any later 4.0.0-* prerelease.
  3. @effect/platform-node-shared@4.0.0-rc.114 went up on npm at 2026-09-11T03:56Z. It has a peer dependency on effect@^4.0.0-rc.114, and that version of effect doesn't exist. The newest published is 4.0.0-rc.113.
  4. npm picks platform-node-shared@rc.114, can't satisfy its peer, and loops on ERESOLVE overriding peer dependency.

t3's published package.json does set overrides that pin every @effect/* package to 4.0.0-beta.103. npm only honors overrides in the root project, though, so they do nothing when t3 is installed as a dependency. The tarball has no npm-shrinkwrap.json, so npm re-resolves every transitive range on each install.

This breaks each path that installs t3 fresh:

  • ensurePinnedRuntimeInstalled (apps/server/src/cloud/pinnedRuntime.ts) runs npm install --prefix <staging> t3@<version> into an empty directory. t3 service install, t3 service update and the remote self-update from the app (apps/server/src/cloud/selfUpdate.ts) all go through it. The install spins until PINNED_RUNTIME_INSTALL_TIMEOUT (10 minutes) kills it.
  • npx t3@0.0.40 ... with no cached copy hangs in npx's own install before any t3 code runs. I saw no output for 5 minutes and got an empty ~/.npm/_npx/<hash> directory.

The nightly should be affected too, since @effect/platform-node@4.0.0-rc.112 asks for @effect/platform-node-shared@^4.0.0-rc.112, which also matches rc.114. I didn't test that one.

A second problem made this hard to find. When the pinned install fails, PinnedRuntimeInstallError records only stdoutLength and stderrLength, not npm's output. On this machine, boot-service.log and server.trace.ndjson* had no trace of the failed attempts at all. The only sign was a changed mtime on ~/.t3/runtime/versions/, left behind when the staging directory got cleaned up.

If effect@4.0.0-rc.114 gets published later, the loop may stop, but npm would then install a second copy of effect next to 4.0.0-beta.103. That looks like the mixed-Effect crash from #2667. So I wouldn't count on this fixing itself.

Possible fixes. Either ship an npm-shrinkwrap.json in the t3 tarball, which npm does honor for dependencies, or have pinnedRuntime.ts write t3's own overrides into the staging package.json before running npm install. Separately, keeping the tail of npm's stderr in PinnedRuntimeInstallError and logging it would have saved about an hour here.

Steps to reproduce

  1. Use a machine with no cached t3@0.0.40 tree, or pass an empty cache: npm_config_cache=$(mktemp -d).
  2. Run npm install --prefix "$(mktemp -d)" --no-fund --no-audit t3@0.0.40. This is the same command ensurePinnedRuntimeInstalled runs.
  3. npm prints the ERESOLVE overriding peer dependency block for @effect/platform-node-shared@4.0.0-rc.114 hundreds of times (727 in my run) and installs nothing. I stopped it after more than 10 minutes.

npx t3@0.0.40 service update and npx t3@latest service update hit the same loop.

Version

0.0.40 (upgrading from 0.0.39)

Environment

Linux x64 6.8.0, Node v22.23.2, npm on PATH at /usr/bin/npm, systemd user service t3code.service, desktop app 0.0.40 on Windows connecting through the relay

Evidence

$ npm view @effect/platform-node@4.0.0-beta.103 dependencies
{
  mime: '^4.1.0',
  undici: '^8.7.0',
  '@effect/platform-node-shared': '^4.0.0-beta.103'
}

$ npm view @effect/platform-node-shared@4.0.0-rc.114 peerDependencies
{ effect: '^4.0.0-rc.114' }

$ npm view @effect/platform-node-shared time | grep -E "rc\.11[34]"
  '4.0.0-rc.113': '2026-09-10T00:42:02.397Z',
  '4.0.0-rc.114': '2026-09-11T03:56:00.008Z'

$ npm view effect versions | tr ',' '\n' | grep -E "rc\.11[0-9]"
  '4.0.0-rc.110'
  '4.0.0-rc.111'
  '4.0.0-rc.112'
  '4.0.0-rc.113'
# no effect@4.0.0-rc.114

$ npm install --prefix /tmp/stage --no-fund --no-audit t3@0.0.40
# >10 min, 727 repeats of the ERESOLVE block above, node_modules never created

# same install with t3's own @effect overrides copied into the root package.json:
added 148 packages in 16s
$ node node_modules/t3/dist/bin.mjs __service-preflight --database-path ~/.t3/userdata/state.sqlite --launcher-protocol 2
{"status":"ready","version":"0.0.40","launcherProtocol":2}

Related issues

#6012 and #9398 are also pinned-runtime install failures, but from native node-pty builds and npm_config_allow_scripts leaking in from npx. Different causes. #2667 is the earlier mixed-Effect-versions crash. I didn't find an existing report of this one.

Fix applied or workaround

I built the pinned runtime by hand with a root package.json that adds t3's own overrides, so npm install resolves in about 17 seconds with a single effect@4.0.0-beta.103:

R=~/.t3/runtime/versions
STAGE=$(mktemp -d "$R/.staging-XXXXXX")
cat > "$STAGE/package.json" <<'EOF'
{
  "dependencies": { "t3": "0.0.40" },
  "overrides": {
    "effect": "4.0.0-beta.103",
    "@effect/platform-node": "4.0.0-beta.103",
    "@effect/platform-node-shared": "4.0.0-beta.103",
    "@effect/platform-bun": "4.0.0-beta.103",
    "@effect/sql-sqlite-bun": "4.0.0-beta.103"
  }
}
EOF
npm install --prefix "$STAGE" --no-fund --no-audit
node "$STAGE/node_modules/t3/dist/bin.mjs" --version    # t3 v0.0.40
echo 0.0.40 > "$STAGE/.install-complete"
mv "$STAGE" "$R/0.0.40"
node "$R/0.0.40/node_modules/t3/dist/bin.mjs" service update

With a complete runtime in place, ensurePinnedRuntimeInstalled skips npm. I ran service update from the pinned CLI instead of npx t3@0.0.40 because npx hits the same loop on its own install. The service came up on 0.0.40 with no restarts and the relay reconnected.

Filed by

Claude Code (claude-opus-5) via t3 triage

Activity

  1. juliusmarminge commented on Sep 11, 2026

    @juliusmarminge
    juliusmarminge
    on Sep 11, 2026
    Member

    Thanks for the write-up — this checks out, and it is a real install-blocking bug.

    Confirmed

    • Published t3@0.0.40 depends on @effect/platform-node@4.0.0-beta.103 (exact). That package depends on @effect/platform-node-shared@^4.0.0-beta.103. npm treats a caret on a prerelease as matching later 4.0.0-* prereleases, so it now selects @effect/platform-node-shared@4.0.0-rc.114 (published 2026-09-11T03:56Z).
    • platform-node-shared@4.0.0-rc.114 peers on effect@^4.0.0-rc.114. That version is not on npm; latest is 4.0.0-rc.113.
    • The published tarball does include overrides pinning @effect/* to 4.0.0-beta.103 (apps/server/scripts/cli.ts copies workspace overrides at publish time). npm only honors overrides on the root project, so they are ignored when t3 is installed as a dependency. _hasShrinkwrap is false.
    • Independently reproduced: npm install --prefix <empty> --cache <empty> --no-fund --no-audit t3@0.0.40 loops on ERESOLVE overriding peer dependency for @effect/platform-node-shared@4.0.0-rc.114 / effect@^4.0.0-rc.114 and never creates node_modules (killed after 25s).

    Impact

    This is not a local-machine issue. Every path that installs t3 into an empty tree hangs:

    • ensurePinnedRuntimeInstalled in apps/server/src/cloud/pinnedRuntime.ts (npm install --prefix <staging> t3@<version>). Used by t3 service install / update (bootService.ts) and remote self-update (selfUpdate.ts). Those wait until PINNED_RUNTIME_INSTALL_TIMEOUT (10 minutes).
    • npx t3@0.0.40 / npx t3@latest hang in npx’s own install before any t3 code runs.

    t3@0.0.39 uses the same Effect pins, so a fresh 0.0.39 install is now broken too. Existing complete pinned runtimes are fine (the sentinel short-circuits npm). Nightly 0.0.41-nightly.20260911.1520 is exposed the same way: @effect/platform-node@4.0.0-rc.112 depends on @effect/platform-node-shared@^4.0.0-rc.112, which also matches rc.114.

    PinnedRuntimeInstallError only records stdout/stderr lengths, which matches the empty boot-service.log / missing npm output.

    Not a duplicate of #6012 / #9398 / #7475 (native node-pty / allow-scripts). Same family as #2667 (mixed Effect from caret ranges); that was addressed in #2676 by publishing overrides, which do not apply for npx / npm install t3@…. No open PR (including #9403, #9380, #10687) fixes this loop.

    Do not wait for effect@4.0.0-rc.114. If that publishes, the loop may stop and npm would likely install a second effect next to 4.0.0-beta.103 / 4.0.0-rc.112 — the mixed-Effect crash from #2667.

    Fix

    1. In pinnedRuntime.ts, write t3’s Effect overrides into the staging root package.json before npm install (unblocks service update and remote self-update). The workaround in the report is this, done by hand.
    2. Ship an npm-shrinkwrap.json in the t3 tarball so npx t3@… cannot re-resolve caret ranges. Today files is only ["dist"].
    3. Keep a tail of npm stderr/stdout on PinnedRuntimeInstallError and log it.

    Until a patched release: if a complete ~/.t3/runtime/versions/<ver> already exists, ensurePinnedRuntimeInstalled skips npm. Otherwise, install with a root package.json that repeats t3’s Effect overrides (as in the report), then run service update from that pinned CLI rather than npx t3@0.0.40.

  2. juliusmarminge
    added
    bugSomething is broken or behaving incorrectly.
    planned
    via-triageFiled through npx t3 triage
    on Sep 11, 2026

  3. vinzenz commented on Sep 11, 2026

    @vinzenz
    vinzenz
    on Sep 11, 2026

    Confirmed the nightly with hard numbers, plus empirical evidence for the "don't
    wait for rc.114" warning (found while debugging this independently — commenting
    here rather than filing a dupe):

    1. Nightly hangs too: npx t3@0.0.41-nightly.20260911.1520 --version with an
      empty cache spins on the identical platform-node-shared@4.0.0-rc.114 /
      effect@^4.0.0-rc.114 ERESOLVE block. Killed after 2 min, zero progress,
      empty ~/.npm/_npx/<hash> dir. A fresh npm install t3@0.0.40 behaves the same.

    2. The mixed-tree crash is real: forcing the install through with
      --legacy-peer-deps yields @effect/platform-node-shared@4.0.0-rc.114 against
      effect@4.0.0-rc.112, and importing platform-node-shared then fails:

      Error [ERR_MODULE_NOT_FOUND]: Cannot find module '.../node_modules/effect/dist/ByteSize.js'

      ByteSize.js doesn't exist in effect rc.112, so rc.114 needs an API that landed
      after it. --help/--version pass on the mixed tree — the crash only shows once
      the server loads the effect stack. Matches the [Bug]: npx t3@0.0.23 startup crash from mixed Effect dependency versions #2667 prediction: rc.114 publishing
      won't fix this cleanly.

    Interim workaround in use (fix #1 done by hand): persistent install dir with
    overrides."@effect/platform-node-shared": "4.0.0-rc.112" + --save-exact; whole
    effect stack on rc.112, CLI verified working. Worth telling people NOT to use
    --legacy-peer-deps as a workaround for the reason above.

    Env: Linux x64, node v24.20.0, npm 12.0.2

  4. neronlux commented on Sep 11, 2026

    @neronlux
    neronlux
    on Sep 11, 2026

    Confirmed on 0.0.41-nightly.20260911.1533, Linux x64, Node v22.23.2, systemd user service.

    Running npx t3@nightly service update reaches the pinned runtime installation, then fails after 10 minutes:

    BootServiceCommandError: Background setup failed while installing the pinned t3 runtime
PinnedRuntimeInstallError
ProcessTimeoutError: Process 'npm' timed out after 600000ms

    npm’s debug log repeatedly shows ERESOLVE for @effect/platform-node-shared@4.0.0-rc.114, requiring effect@^4.0.0-rc.114. A direct registry query for effect@4.0.0-rc.114 returned E404.

    The existing service remained running with the same PID and start time. The update did not complete.

    Investigated using Codex (GPT-6) via t3 triage.

  5. neronlux commented on Sep 11, 2026

    @neronlux
    neronlux
    on Sep 11, 2026

    Workaround confirmed for 0.0.41-nightly.20260911.1533 on Linux x64 with Node v22.23.2:

    1. Created a staging directory under ~/.t3/runtime/versions/ with a root package.json containing the exact T3 version and its published Effect overrides, all pinned to 4.0.0-rc.112, including @effect/platform-node-shared.
    2. Ran npm install --prefix <staging> --no-fund --no-audit. Installation completed in 12 seconds.
    3. npm blocked native install scripts, so ran npm install-scripts approve node-pty msgpackr-extract and npm rebuild node-pty msgpackr-extract inside staging.
    4. Verified a single Effect rc.112 dependency tree, native module loading, Effect NodeFileSystem import, CLI version, and launcher preflight (ready).
    5. Wrote the exact version to .install-complete, moved staging to ~/.t3/runtime/versions/0.0.41-nightly.20260911.1533, and ran node <runtime>/node_modules/t3/dist/bin.mjs service update.

    The update succeeded. Service status confirmed the target nightly; systemd reported active/running with zero automatic restarts. No --legacy-peer-deps or T3 source patches were used.

    Verified using Codex (GPT-6) via t3 triage.

  6. heymaaz commented on Sep 11, 2026

    @heymaaz
    heymaaz
    on Sep 11, 2026

    Happened with me as well:

    maazchowdhry@MacBook-Pro-2 hackathon % npx t3@nightly
Need to install the following packages:
t3@0.0.41-nightly.20260911.1533
Ok to proceed? (y)
npm warn ERESOLVE overriding peer dependency
npm warn While resolving: @effect/platform-node-shared@4.0.0-rc.114
npm warn Found: peer effect@"^4.0.0-rc.114" from the root project
npm warn
npm warn Could not resolve dependency:
npm warn peer effect@"^4.0.0-rc.114" from the root project
npm warn ERESOLVE overriding peer dependency
npm warn While resolving: @effect/platform-node-shared@4.0.0-rc.114
npm warn Found: peer effect@"^4.0.0-rc.114" from the root project
npm warn
npm warn Could not resolve dependency:
npm warn peer effect@"^4.0.0-rc.114" from the root project
npm warn ERESOLVE overriding peer dependency
npm warn While resolving: @effect/platform-node-shared@4.0.0-rc.114
npm warn Found: peer effect@"^4.0.0-rc.114" from the root project
npm warn
npm warn Could not resolve dependency:
npm warn peer effect@"^4.0.0-rc.114" from the root project
npm warn ERESOLVE overriding peer dependency
npm warn While resolving: @effect/platform-node-shared@4.0.0-rc.114
npm warn Found: peer effect@"^4.0.0-rc.114" from the root project
npm warn

    using pnpm with these commands work:

    maazchowdhry@MacBook-Pro-2 hackathon % pnpm dlx --allow-build=node-pty --allow-build=msgpackr-extract t3@nightly
[14:50:42.272] INFO (#287): Listening on http://127.0.0.1:3773
[14:50:42.281] INFO (#286): agent activity publishing standby; waiting for T3 Connect link reconciliation
[14:50:42.282] INFO (#286): provider.session.reaper.started
  { inactivityThresholdMs: 1800000, sweepIntervalMs: 300000 }
[14:50:42.361] INFO (#512): Authentication required. Open T3 Code using the pairing URL.

  7. heymaaz commented on Sep 11, 2026

    @heymaaz
    heymaaz
    on Sep 11, 2026

    Related: Effect-TS/effect#8186 (comment)

  8. neronlux commented on Sep 11, 2026

    @neronlux
    neronlux
    on Sep 11, 2026

    Confirmed this still affects 0.0.41-nightly.20260911.1547. Following up on my earlier .1533 report: the newer nightly also required the workaround.

    Environment: Linux x64, Node v22.23.2, npm 12.0.2, systemd user service.

    The service update failed with:

    BootServiceCommandError: Background setup failed while installing the pinned t3 runtime
PinnedRuntimeInstallError
ProcessTimeoutError: Process 'npm' timed out after 600000ms

    The npm debug log repeatedly selected @effect/platform-node-shared@4.0.0-rc.114, requiring effect@^4.0.0-rc.114, while T3 pins effect@4.0.0-rc.112. A registry query for effect@4.0.0-rc.114 still returned E404 during diagnosis.

    Recovery that worked on this machine

    1. Created a staging directory under ~/.t3/runtime/versions/ with this root package.json:

      {
  "private": true,
  "dependencies": { "t3": "0.0.41-nightly.20260911.1547" },
  "overrides": {
    "effect": "4.0.0-rc.112",
    "@effect/platform-node": "4.0.0-rc.112",
    "@effect/platform-node-shared": "4.0.0-rc.112",
    "@effect/platform-bun": "4.0.0-rc.112",
    "@effect/sql-sqlite-bun": "4.0.0-rc.112"
  }
}

    2. Ran npm install --prefix <staging> --no-fund --no-audit. This installed 141 packages in 11 seconds, with the Effect tree consistently on rc.112.

    3. npm 12 blocked the native install scripts. Inside the new runtime directory, ran npm install-scripts approve msgpackr-extract node-pty, then npm rebuild msgpackr-extract node-pty --foreground-scripts. Both rebuilt successfully; a node-pty spawn test printed pty-ok and exited 0.

    4. Verified the CLI version and launcher preflight (ready, expected version, protocol 2), recorded the version in .install-complete, and published the staged runtime as ~/.t3/runtime/versions/0.0.41-nightly.20260911.1547.

    5. Ran the installed CLI's service update. The first attempt hit a separate stopping the installed service (exit code 1) error, after which the previous version was running again. A direct systemctl --user stop t3code.service succeeded; then this completed successfully:

      node ~/.t3/runtime/versions/0.0.41-nightly.20260911.1547/node_modules/t3/dist/bin.mjs service update

    Final verification: systemd showed the server process running from the .1547 runtime, active/running with zero automatic restarts, and the local server returned HTTP 200. The cause of the separate service-stop error was not established.

    This is a per-version runtime workaround; the normal fresh-install dependency resolution remains broken. No T3 source patch or --legacy-peer-deps was used.

    Investigated and recovery verified using Codex (GPT-6) via t3 triage.

  9. juliusmarminge commented on Sep 11, 2026

    @juliusmarminge
    juliusmarminge
    on Sep 11, 2026
    Member

    Closed as fixed by #11240 (pin @effect/platform-node-shared as a direct catalog dependency so fresh npm installs stop floating onto rc.114 once a new release is published).

  10. juliusmarminge
    closed this as completedon Sep 11, 2026

  11. fubhy commented on Sep 11, 2026

    @fubhy
    fubhy
    on Sep 11, 2026

    @juliusmarminge you (or Theo) don't happen to know someone at npm, do you? Effect-TS/effect#8186 (comment)

    We are stuck with some side effects (heh) from this here apparently: https://github.blog/changelog/2026-07-28-npm-publish-time-malware-scanning-and-dual-use-metadata/

  12. fubhy commented on Sep 11, 2026

    @fubhy
    fubhy
    on Sep 11, 2026

    @juliusmarminge v4.0.0-rc.115 is now published. I don't know why or how but it's green and installable.

  13. thurstonsand
    added a commit that references this issue on Sep 12, 2026

    fix(pod042): install T3's CLI the way T3 installs itself

    c9b2a2c
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething is broken or behaving incorrectly.plannedvia-triageFiled through npx t3 triage

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions