[BUG] Regression: ~1s fixed overhead per spawned child process via Bash/PowerShell tools (Windows)

Status Open
Maintainer reply None cached
Activity 0 comments · opened Jul 26, 2026

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?

Summary

Starting sometime yesterday (possibly the day before), every child process spawned through the Bash/PowerShell tool execution path has picked up a consistent ~1 second of fixed overhead, regardless of how trivial the process is. This wasn't present before — the same workflow was fast until this recent onset.

Environment

OS: Windows 11 Pro (build 10.0.26200)
Shell tools used: PowerShell (primary), Bash tool
Workflow: agent-invoked Start-Process / direct command execution against a local project
Evidence

Isolated the overhead with trivial process spawns, ruling out disk I/O and the target executable itself:

No orphaned MSBuild.exe/VBCSCompiler.exe/dotnet.exe processes were present before testing, so it isn't leftover-process contention.

Real-world impact

A mid-sized .NET 7 WinForms solution that builds in ~2 seconds via MSBuild.exe natively (confirmed via the user's own Visual Studio, same machine, same solution) took 5-10+ minutes when the identical MSBuild.exe command was invoked through the agent's PowerShell tool. A full build for this solution spawns on the order of hundreds of child/task processes (compiler tasks, resource compiler, post-build file copies); at ~1s of fixed overhead per spawn, that fully accounts for the slowdown.

What this rules out

Not VS/compiler-server contention — Visual Studio was not even running during the slow builds.
Not disk I/O — sub-50ms for both a RAM-backed drive and a large recursive directory scan.
Not the target project or antivirus in the general sense — a bare cmd.exe /c exit shows the same ~1s tax, and the user's own native shell/VS usage on the identical machine is unaffected.

What Should Happen?

Ask

This looks like a regression in whatever layer mediates/monitors process creation for the Bash/PowerShell tools (sandboxing, auditing, etc.) —

Error Messages/Logs

Steps to Reproduce

ask Claude To make a small edit to a Visual Studio C# project. Claude offers to compile to ensure that the edit caused no problems. What up until a couple of days ago took no more than a couple of seconds is now taking 10+ minutes To build a test compile.

Claude Model

Sonnet (default)

Is this a regression?

Yes, this worked in a previous version

Last Working Version

2-3 days ago, worked fine

Claude Code Version

1.24012.9.0 (7/24/2026)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

_No response_

View original on GitHub ↗