[BUG] Claude-spawned child shells on Windows can't complete new outbound TLS handshakes to non-Anthropic endpoints (breaks Perforce)

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?

Recreated https://github.com/anthropics/claude-code/issues/58811 since the bot auto closed it without anyone touching it or fixing it...

Summary

On Windows, processes spawned as descendants of claude.exe (the tool-call PowerShell shell, and its children like p4.exe) cannot complete new outbound TLS handshakes to non-Anthropic endpoints. TCP succeeds, the TLS handshake
stalls (no ServerHello arrives), the call eventually times out. The exact same call from a non-Claude terminal on the same machine — or from a process spawned outside Claude's process tree via WMI — succeeds instantly.

For teams using Perforce-controlled repos (game dev, hardware, large monorepos), this is a hard blocker: Claude Code on Windows can read files but can't run p4 edit to check them out, so any code change against a checked-in
file fails until the user manually checks it out from a different terminal.

Note: CLAUDE_CODE_PERFORCE_MODE (added in 2.1.98) helps the read-only-file half of the workflow by making Edit/Write/NotebookEdit fail fast with a p4 edit hint, but it doesn't address this issue — the suggested p4 edit
command itself still hangs at TLS handshake from inside the Claude shell.

Environment

OS: Windows 11 Pro 10.0.26200
Shell: PowerShell 7.6.1 (Core)
Claude Code: 2.1.140
Process tree at failure: pwsh.exe (tool call) ← claude.exe ← powershell.exe (Rider terminal integration) ← rider64.exe
Other AV on box: Norton Security — fully ruled out (disabling all Norton components didn't change the symptom; p4 info works fine from non-Claude terminals with Norton at its normal settings).
Reproducer

From inside a Claude Code shell on Windows:

p4 -p ssl:<PERFORCE_HOST>:1666 info

Returns after ~30s:

Perforce client error:
SSL connect to ssl:<PERFORCE_HOST>:1666 timed out.

The same command from a separately-opened terminal (Win+R → pwsh) returns the server info immediately.

Diagnostic findings

TCP three-way handshake to the depot's IP succeeds from inside the Claude shell (Test-NetConnection reports TcpTestSucceeded: True).
TLS handshake never receives a ServerHello — confirmed both via p4.exe (OpenSSL) and via bare .NET SslStream invoked from PowerShell 7 (modern .NET 8 SSL stack). Same symptom for both, same timeout, no MITM cert ever
delivered.
Bare .NET SslStream to google.com:443 from the same shell works fine — so this is destination-specific, not "all TLS broken."
IsProcessInJob(GetCurrentProcess(), NULL, &result) on the Claude tool-call shell returns True — Claude is placing its descendants in a Windows Job Object.
Spawning p4.exe via Invoke-CimMethod Win32_Process Create (so the new process is parented by svchost, escaping Claude's process tree) succeeds instantly from inside a Claude shell — same machine, same network, same p4.exe
binary, same user identity. This is what nailed down the cause.
JetBrains Rider's PerforcePlugin.exe (P4Java, JVM SSL stack) makes new handshakes to the same depot at the same time and they succeed — confirming the depot and the network path are fine; only Claude descendants are
blocked.
Probable cause

A WFP / Winsock filter (or similar network-policy mechanism) is attached to the Windows Job Object that claude.exe places its children in, silently dropping outbound TLS handshakes from job members to non-allowlisted
endpoints. The Anthropic API endpoint is presumably on the allowlist since Claude Code itself talks to the API fine.

This is not a per-version regression in the binary — the same claude.exe 2.1.140 build worked for the user with Perforce in one workspace a few hours before failing in another. Some state or configuration drives the
enablement.

Workaround

Route p4 commands through WMI to spawn them outside Claude's process tree:

$outFile = "C:\Users<USERNAME>\AppData\Local\Temp\claude-p4-out.txt"
if(Test-Path $outFile) { Remove-Item $outFile -Force }
$cmd = "cmd /c ""C:\Program Files\Perforce\p4.exe" -c <CLIENT> <ARGS> > "$outFile" 2>&1""
$result = Invoke-CimMethod -ClassName Win32_Process -MethodName Create -Arguments @{
CommandLine = $cmd
CurrentDirectory = "<WORKSPACE_ROOT>"
}
$deadline = (Get-Date).AddSeconds(30)
while((Get-Date) -lt $deadline) {
if(-not (Get-Process -Id $result.ProcessId -ErrorAction SilentlyContinue)) { break }
Start-Sleep -Milliseconds 300
}
Get-Content $outFile

This works reliably but is a deliberate sandbox bypass — the responsibility is now on the user to authorize Claude to use it.

NOTE this was written by claude after helping it debug

What Should Happen?

Suggested fix

One of:

1. Allowlist Perforce traffic in the Job-Object-bound network policy by default. Perforce ops happen constantly during normal editing flow on a Perforce-controlled repo; gating them silently isn't workable. A simple p4.exe /

p4vc.exe / p4broker.exe exemption (similar in spirit to how CLAUDE_CODE_PERFORCE_MODE already specifically recognizes Perforce-flavored read-only failures) would cover the common case.

1. Provide a documented user-facing allowlist for outbound TLS targets — e.g., a networkAllowlist field in settings.json listing host:port pairs the user trusts. Useful beyond Perforce (private registries, internal git over

SSL, corporate Jira/Confluence APIs called from custom hooks/scripts, etc.).

1. Surface the containment in claude doctor / --version so users can see what their session can and can't reach. We spent hours chasing Norton red herrings before tracing it to Claude's Job Object — IsProcessInJob returning

True plus a list of blocked outbound destinations would have saved that time. Documenting the containment in CLAUDE_CODE_PERFORCE_MODE's reference page would also help, since users currently set that flag and reasonably
assume it will unblock the matching p4 edit call — but the network containment then prevents the very command the hint tells them to run.

NOTE this was written by claude after helping it debug

Error Messages/Logs

Perforce client error:
  SSL connect to ssl:<PERFORCE_HOST>:1666 timed out.

Steps to Reproduce

Reproducer

From inside a Claude Code shell on Windows:

p4 -p ssl:<PERFORCE_HOST>:1666 info

Returns after ~30s:

Perforce client error:
SSL connect to ssl:<PERFORCE_HOST>:1666 timed out.

The same command from a separately-opened terminal (Win+R → pwsh) returns the server info immediately.

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

2.1.140

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

It was working until I opened a different project with claude (both Rider), but then it stopped working for both. Claude assured me that opening a different project didn't change anything. It compared the project/rider/perforce settings for both and said there were no differences other than workspace name