[BUG] Headless first-stream latency regresses between 2.1.197 and 2.1.200 on Linux arm64

Preflight Checklist

• [x] I searched existing issues and did not find this measured regression.
• [x] This is a single bug report.
• [x] I reproduced on the latest release, 2.1.222.

What is wrong?

Headless, schema-bound claude -p invocations on Linux arm64 take materially longer to emit their first stream event beginning around 2.1.198-2.1.200. The added delay persists through 2.1.222.

I ran checksum-verified release binaries on the same host, against the same OAuth account, model, fixed prompt, and fixed JSON schema. Each row is one warmup plus five measured invocations.

| Version | Median first stdout | Median first provider event | Median process total |
|---|---:|---:|---:|
| 2.1.190 | 1535 ms | 4065 ms | 5765 ms |
| 2.1.197 | 1553 ms | 3839 ms | 5174 ms |
| 2.1.198 | 1650 ms | 4206 ms | 5472 ms |
| 2.1.199 | 1766 ms | 3923 ms | 5643 ms |
| 2.1.200 | 2194 ms | 4948 ms | 7044 ms |
| 2.1.201 | 2237 ms | 4353 ms | 6056 ms |
| 2.1.205 | 2143 ms | 4218 ms | 5968 ms |
| 2.1.212 | 2133 ms | 4862 ms | 6334 ms |
| 2.1.219 | 2224 ms | 4783 ms | 6191 ms |
| 2.1.220 | 2265 ms | 4552 ms | 6782 ms |
| 2.1.222 | 2295 ms | 4400 ms | 5970 ms |

The ordinary binary startup difference is small: 30 warm --version samples measured 99.4 ms median on 2.1.141 and 118.7 ms on 2.1.220. The extra headless delay therefore appears after process startup, in CLI/session initialization or handshake rather than executable loading.

Setting CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1 did not fix it (2.1.220 median first stdout remained 2174 ms).

What should happen?

Headless one-shot startup should not add roughly 0.6-0.8 seconds before the first stream event compared with 2.1.190/2.1.197. Ideally the initialization work introduced around 2.1.198-2.1.200 is made lazy, cached, or removed for -p calls.

Steps to reproduce

1. Download checksum-verified Linux arm64 release binaries for 2.1.197, 2.1.200, and 2.1.222.
2. Use the same authenticated config directory and the same model for every run.
3. Pipe the same prompt to each binary with -p - --model claude-haiku-4-5 --output-format stream-json --include-partial-messages --verbose --max-turns 2 --tools "" --effort low --json-schema <fixed-schema>.
4. Record monotonic time from process spawn to the first stdout chunk / first JSON stream event.
5. Run at least one warmup and five measured samples per version.

Error messages/logs

No error is emitted. Calls complete successfully; this is a repeatable latency regression.

Claude model

Haiku (fixed for all samples).

Is this a regression?

Yes.

Last working version

2.1.197 is consistently fast. 2.1.198 and 2.1.199 show a smaller increase; the large step is present by 2.1.200.

Claude Code version

2.1.222 (Claude Code), also reproduced across 2.1.198-2.1.220.

Platform

Anthropic API / OAuth subscription.

Operating system

Ubuntu/Debian Linux, arm64.

Terminal/shell

Non-interactive service environment.

Additional information

All binaries were official GitHub release artifacts and were checked against the release SHASUMS256 file before execution. No pin is being recommended internally because the nearest meaningfully faster client is now many releases old; this report is intended to make the regression independently reproducible upstream.