[FEATURE] Desktop: coordinate heavy local work across concurrent sessions instead of letting every session build at once

Status Open
Reported on v2.1.296
Maintainer reply None cached
Activity 0 comments · opened Oct 11, 2026

Problem

On a single Mac, several Claude Code sessions (desktop app Code tab, plus their subagents and workflows) run at the same time. Each session decides on its own to start heavy local work: Gradle, xcodebuild and simulators, cargo, Flutter, test suites, pre-push verify scripts. None of them knows what the others are doing, so they all start building at once.

The result is the machine thrashing itself. Example from our setup (MacBook Pro, 11 cores, 18 GB RAM): 11 agents plus a 5-agent workflow drove the load average to ~726 with swap full. Every build ran far slower than if they had run one after another. Another day, seven parallel agents each running a pre-push verify queued on one shared cargo lock and turned a 17-minute gate into over two hours of wall clock.

Today the only fix is for the user to build their own coordination layer: we wrote a machine-wide semaphore script (2 heavy slots), a "check capacity" script every session must run before fanning out, a PreToolUse hook that refuses Agent/Workflow calls while the machine is overloaded, and instructions in CLAUDE.md telling every agent to wrap heavy commands. That is a lot of infrastructure for something the app is in a much better position to own.

What I'd expect

Device-aware execution should be the app's job, not the end user's:

  • A machine-wide scheduler across sessions. The desktop app knows every session it is running. Heavy local commands (or a user-declared list of them) should go through a shared queue with a concurrency limit derived from cores and free memory, not each session's own guess.
  • Sessions that adapt to load. Before spawning subagents or a workflow, and while they run, a session should see current CPU/memory pressure and back off, serialize, or wait instead of piling on.
  • Visibility. A simple view of "what is building right now, from which session, and what is queued" so the user can see the clog instead of just feeling the fans.
  • Recognize contention. When two sessions wait on the same lock (cargo, Gradle daemon, simulator), detect it and tell the session instead of letting it sit.

Related

  • #99267 (Workflow concurrency counts agents, not command weight; no cap across sessions)
  • #91081 (resource governance for agent-spawned process trees)
  • #88524 (memory scales with open sessions on macOS)

Environment

  • Claude desktop app 2.31226.1, Claude Code 2.1.296
  • macOS 27.0.1, MacBook Pro, 11 cores, 18 GB RAM

View original on GitHub ↗