Show Linux agent memory limits and sustained throttling

[satyalyadav]

Please show when agent work is making little progress because it is under sustained memory pressure, and expose the shared memory budget for Linux execution environments, including WSL.

In #18350, two concurrent dependency installs occupied one Codex scope. The shared agents slice used about 3.43 GiB against a 3.35 GiB soft threshold and a 5.03 GiB hard limit. It also used about 1.46 GiB of swap. The guest's 2 GiB swap was full, memory stalls were severe, and the client showed reconnecting. The captured cgroup counters recorded no OOM kill.

The triage reply classified the transport failure as an upstream WSL problem, confirmed that soft-limit throttling is intentional, and directed configurable thresholds and pressure warnings to Ideas. This example does not establish that the soft limit alone caused the WSL failure.

Suggested behavior:

• Show the execution environment's shared agent memory use, soft threshold, hard limit, and swap use. Explain that the budget covers multiple agent scopes and is not a separate allowance for each thread.
• Warn about sustained pressure using available stall measurements and changes in throttling counters. A brief threshold crossing or a cumulative event count alone should not imply that work is stuck. Link to the existing resource diagnostics and responsible commands where ownership is known.
• If the backend disconnects, label retained measurements as last known and show their age. Do not display stale pressure as a current diagnosis.
• Consider optional shared-budget settings with the current defaults retained. Show the resulting limits and validate their relationship. Explain that raising a threshold can increase pressure elsewhere and cannot guarantee protection from WSL allocation failures.

The warning should help users decide whether to wait or run expensive commands one at a time. It should preserve active work and should not automatically terminate commands or change resource limits.

Ideas #15449 already proposes workload attribution and sustained-load warnings. This request adds the Linux shared-budget and soft-throttling context, plus an optional configuration follow-up. It could build on that proposal rather than require a separate monitoring system.

Sequential-install testing is still pending. No threshold change has been tested, and this is a request for visibility and configuration rather than a claim that either would fix the underlying WSL bug.

[juliusmarminge]

Note

Grok responding on behalf of Julius.

Thanks for the detailed write-up. This overlaps heavily with #15449, which already covers sustained memory-pressure warnings, configurable thresholds, and linking warnings to the existing resource diagnostics. Closing this as a duplicate so the idea lives in one place. Please add the Linux shared-budget details (soft/hard limits, swap, the WSL case from #18350, and stale-data labeling after disconnects) as a comment on #15449.