bun install hangs indefinitely in Claude Code remote environment for large monorepos

TL;DR

bun install hangs at "Resolving dependencies" for large monorepos (~6000 packages) in Claude Code remote/web sessions. The same codebase installs in ~1 minute locally. The hang occurs even with --offline, suggesting an issue with bun's in-memory resolution algorithm in this environment rather than network I/O.

---

Environment

| Property | Value |
|----------|-------|
| Claude Code Environment | Remote (web-based, CLAUDE_CODE_REMOTE=true) |
| Bun Version | 1.3.5 |
| OS | Linux 4.4.0 |
| RAM | 21GB available |
| CPUs | 16 |
| Disk | 27GB available |

Description

bun install hangs indefinitely at the "Resolving dependencies" phase in the Claude Code remote environment, even for a monorepo that installs successfully in ~1 minute on a local M3 Mac.

The same codebase has been successfully installed in multiple other environments (local macOS, CI, other cloud VMs) without issues.

Reproduction Steps

1. Open Claude Code web session with a monorepo containing ~6000 packages in lockfile (12 workspaces)
2. Run bun install --ignore-scripts
3. Observe it hangs at "Resolving dependencies" indefinitely (tested 60+ seconds with no progress)

Diagnostic Evidence

1. Small package works fine

$ cd /tmp && bun add lodash
# Completes in 434ms

2. Network is functional

$ curl -sI https://registry.npmjs.org/
HTTP/1.1 200 OK

3. Offline mode also hangs (rules out network)

$ bun install --ignore-scripts --offline
# Still hangs at "Resolving dependencies"

4. Cache exists and is populated

$ du -sh ~/.bun/install/cache
2.5G with 5010 packages

5. strace shows connections go through proxy

connect(14, {sa_family=AF_INET, sin_port=htons(15004),
        sin_addr=inet_addr("21.0.0.113")}, 16)
sendto(14, "CONNECT registry.npmjs.org:443 H"..., 1148, ...)
recvfrom(14, "HTTP/1.1 200 OK\r\n..."...)

Network operations succeed (TLS handshake completes), but resolution never finishes.

6. Resources are not constrained

$ free -h
              total        used        free      shared  buff/cache   available
Mem:           21Gi       380Mi        20Gi          0B       126Mi        20Gi

$ nproc
16

$ df -h /
Filesystem      Size  Used Avail Use% Mounted on
none             30G  2.8G   27G  10% /

Key Observations

• The same monorepo installs in ~1 minute on a local M3 Mac
• Simple packages (e.g., lodash) install instantly in the remote environment
• The hang occurs even with --offline flag, suggesting it's not purely network-related
• The hang occurs even with --frozen-lockfile flag
• The issue appears specific to bun's dependency resolution algorithm behavior in this environment
• Removing the lockfile and regenerating also hangs

Suspected Cause

Something in the Claude Code remote environment (possibly related to process scheduling, sandboxing, or the HTTP proxy at 21.0.0.113:15004) causes bun's resolution algorithm to hang or run extremely slowly for large dependency graphs.

Since --offline mode also hangs, this suggests the issue is in bun's in-memory resolution algorithm rather than network I/O.

Workarounds Attempted

| Workaround | Result |
|------------|--------|
| --frozen-lockfile | Still hangs |
| --offline | Still hangs |
| Remove lockfile and regenerate | Still hangs |
| bun upgrade (1.3.4 → 1.3.5) | No improvement |
| Install in subdirectory/single workspace | Still hangs |

Impact

This blocks any development work that requires node_modules in Claude Code web sessions for projects with large dependency trees. Tools like tsgo, biome, and other npm-based tooling become unavailable.

Severity: High - effectively makes Claude Code web unusable for large JavaScript/TypeScript monorepos.

Suggested Investigation Areas

1. Is there process/thread throttling in the container that affects bun's parallel resolution algorithm?
2. Does the HTTP CONNECT proxy introduce latency that compounds with many packages?
3. Is there a file descriptor or socket limit that affects bun's connection pool?
4. Is there memory allocation behavior (e.g., mmap limits) that affects bun's data structures?
5. Is there something specific about how bun parses large lockfiles in this environment?

Monorepo Characteristics

• 12 workspaces (apps/*, packages/*)
• ~6000 packages in bun.lock (731KB lockfile)
• Mix of dependencies including React 19, Convex, Effect, TipTap, etc.
• Standard bun workspace configuration

Related

• Bun version: 1.3.5 (latest as of testing)
• No bunfig.toml or custom configuration
• No .npmrc file