[BUG]

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

When Claude Code runs inside a Docker container, there is a multi-second delay between pressing Enter on a prompt and Claude Code registering it. The same repository, on the same machine, with the same Claude Code version, has no such delay when Claude Code is run natively on the host.

Native on the host, large repo: no delay.
Docker container, same repo: ~14.7 seconds.

During the delay the terminal is completely unresponsive — typing does nothing and text selection is also blocked. Nothing is written to the debug log during the gap.

Once the input finally registers, [engine] turn 1 start fires ~30ms later and the API round trip is normal (~1.0–1.8s to first byte, ~2.0–2.3s total). The model response is not the slow part; the delay happens before Claude Code acts on the input at all.

Inside the container, the delay also scales with project size:

| Environment | Working directory | Delay |
|---|---|---|
| Native (host) | Large repo | None |
| Docker container | Large repo (4,706 tracked + 932 untracked files) | ~14.7s |
| Docker container | Small folder | ~3.6s |

The first prompt of a session is the worst. Later prompts in the same session are faster, suggesting a one-time cost that warms up.

Debug log excerpt, container + large repo:

08:43:29.181  Plugin autoupdate: skipped (auto-updater disabled)   <- last startup line
              [~14.7s gap, nothing logged]
08:43:43.860  LSP Diagnostics: getLSPDiagnosticAttachments called   <- input registers
08:43:43.892  [engine] turn 1 start
08:43:45.015  [API:timing] first byte after 1116ms
08:43:46.223  [engine] turn 1 end (api=2322ms)

Debug log excerpt, container + small folder, identical container and terminal:

08:54:09.006  Fast mode unavailable                                <- last startup line
              [~3.6s gap]
08:54:12.608  [engine] turn 1 start
08:54:13.639  [API:timing] first byte after 1023ms
08:54:14.611  [engine] turn 1 end (api=1994ms)

What Should Happen?

Input latency inside a container should be comparable to native. A trivial prompt that requires no file access should register immediately regardless of whether Claude Code is containerized, and regardless of how many files are in the project directory. The terminal should stay responsive to typing and text selection while a prompt is being processed.

Error Messages/Logs

Steps to Reproduce

1. Run claude --debug natively on the host, in a large project directory. Send a short prompt (e.g. "hello"). Note that it registers immediately.
2. Run claude --debug inside a Docker dev container with the same project bind-mounted at /workspace. Send the same prompt.
3. Observe the multi-second delay before the response begins, and that the terminal is unresponsive throughout.
4. Optionally repeat step 2 with a small folder as the working directory to see the delay shrink.

Claude Model

Opus

Is this a regression?

No, this never worked

Last Working Version

_No response_

Claude Code Version

2.1.248.5e3 (Claude Code)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

What was ruled out

Each of the following was tested and eliminated, with the delay unchanged:

| Hypothesis | How it was excluded |
|---|---|
| Docker Desktop Resource Saver (VM auto-pause) | Disabled and Docker restarted; no change |
| Claude Code's nested OS sandbox | Rebuilt with sandbox.enabled: false; no change |
| Bind-mount filesystem watcher cost | Moved node_modules and build directories into container-managed volumes with volume-nocopy; file index dropped 780ms → 18ms, delay unchanged |
| VirtioFS vs gRPC FUSE file sharing | Both tested; no change |
| Terminal emulator rendering / missing synchronized output | Reproduced in two terminal emulators. One log confirms XTVERSION: terminal identified as "iTerm2 3.6.11" and DECRQM(2026): status=2 → sync supported; delay unchanged (14.7s vs 14.5s) |
| Docker TTY input path | Shell typing inside the same container is instant, both before running claude and after exiting it |
| Bloated ~/.claude.json | 44 KB total, of which 31 KB is cachedGrowthBookFeatures; project history is ~1.8 KB |
| Repeated localSettings: not canonicalizing the consent store warnings (hundreds per session, from a root-owned /workspace mount point) | Fixed by chowning the mount point; warning count now 0, delay unchanged |
| Claude Code itself / project size in general | Native run on the same large repo has no delay at all |

Container configuration

The container runs Claude Code as a non-root user (uid 1000) with the project bind-mounted at /workspace, --cap-drop=ALL plus NET_ADMIN, NET_RAW, SETUID, SETGID, CHOWN, and --security-opt=no-new-privileges. Managed settings are baked in at /etc/claude-code/managed-settings.json (sandbox enabled, permission allow/deny/ask rules, network allowlist enforced by an iptables/ipset egress firewall installed at container start).

Note that with the nested sandbox disabled (sandbox.enabled: false) the delay persists unchanged, so this does not appear to be sandbox-related.

Unresolved observation

Reducing terminal width from 167 to ~100 columns cut the delay from ~23.8s to ~14.5s, which initially suggested a rendering cost. But a terminal with confirmed synchronized-output support showed no improvement at all. Width and containerization appear to be independent contributors, and the width effect is not explained by the usual synchronized-output fallback.

Other notes

• Resource allocation is not a constraint: 10 CPUs / 8 GB assigned to Docker Desktop.
• No [event-loop-stall] warnings appear in sessions where synchronized output is supported.
• The project has a CLAUDE.md at its root of roughly 9,100 characters, loaded into every session.
• Possibly related: #53166 (TUI input lag where terminal and Claude Code process both profile as idle — same "nothing is busy, still slow" conclusion, different trigger).