subagent-limit-guard still unconditionally rewrites [features.multi_agent_v2] max_concurrent_threads_per_session = 1000 (v4.17.0) — v2 follow-up to #97

[catallactics]

Summary

ensureSubagentConcurrencyLimit() ends by calling ensureMultiAgentV2ThreadLimit(result) unconditionally, and that helper writes [features.multi_agent_v2] max_concurrent_threads_per_session = 1000 into the user's config.toml on every run — creating the section if absent, and overwriting any user-set value if present. This happens regardless of the selected model, and there is no equivalent of the "hand-removed key stays removed" behavior that the same file deliberately implements for the legacy agents.max_threads path.

Pinned source at v4.17.0 (f39306f):

• Constant CODEX_SUBAGENT_THREAD_LIMIT = "1000": subagent-limit-guard.mjs#L5
• Unconditional call at the end of ensureSubagentConcurrencyLimit: subagent-limit-guard.mjs#L38
• Writer that inserts/overwrites the key: subagent-limit-guard.mjs#L81-L90

Why it matters

On multi_agent_v2 sessions (e.g. gpt-5.6-sol), max_concurrent_threads_per_session is effectively the only concurrency gate that holds:

• agents.max_depth is not enforced on the v2 spawn path (agents.max_depth = 1 permits child-to-grandchild spawning in 0.144.1 openai/codex#32027, still open)
• the v2 non-root thread limit is derived from this cap (cap − 1)
• in our testing on codex-cli 0.144.1, [features.multi_agent_v2] enabled = false did not disable v2 for gpt-5.6-sol — model catalog metadata took precedence

We audited a runaway session on codex-cli 0.144.1 + gpt-5.6-sol where the injected runtime hint "There are 1000 available concurrency slots" appeared 23× in the rollout, alongside a spawn tree of 1,004 descendant threads (depth 11) and ~46 GB RSS before manual intervention. After we restored Codex's stock default (cap 4) by deleting the override, source inspection showed this migration would silently re-write 1000 on the next session start with the plugin enabled — i.e. a user who fixes their config gets re-broken.

What v4.17.0 already improved (appreciated)

• v2-preferring models now get agents.max_threads removed instead of written (the v2Preferred branch in ensureSubagentConcurrencyLimit), and a hand-removed key stays removed on the no-model-evidence path
• the GPT-5.6: managed multi_agent_v2=false causes reserved collaboration.spawn_agent schema error #118 stale hide_spawn_agent_metadata cleanup works as described

The v2 cap write is the remaining piece of #97.

Suggested fix

Any of, in order of preference:

1. Stop writing max_concurrent_threads_per_session unless the user opts in
2. Honor existing / hand-removed user values, mirroring the raiseExistingAgentsMaxThreads philosophy already applied to the v1 key
3. At minimum, make the limit configurable instead of hard-coding "1000"

LAZYCODEX_CONFIG_MIGRATION_DISABLED=1 exists but is all-or-nothing — enabling it also loses the genuinely useful guards (e.g. the #118 cleanup).

Environment

• codex-cli 0.144.1, model gpt-5.6-sol (multi_agent_v2), macOS
• Originally observed with OMO 4.15.1; behavior confirmed by source inspection at v4.17.0 (f39306f)

[ameforce]

Independent Windows-native confirmation

I independently reproduced the unsafe amplification described here on native Windows Codex Desktop. This adds runtime, A/B, and actual spawn-tree evidence to the source-level report above.

Environment

• Windows 11 10.0.26200 x64
• Codex Desktop MSIX 26.707.8168.0
• codex-cli 0.144.1
• LazyCodex / omo@sisyphuslabs 4.17.0
• Model: gpt-5.6-sol / MultiAgentV2
• Install: npx --yes lazycodex-ai@4.17.0 install --no-tui --codex-autonomous

Reproduction

1. Install and enable LazyCodex 4.17.0 in Codex Desktop.
2. Let SessionStart/bootstrap run with several existing chats and run normal subagent/review workloads.
3. Remove [features.multi_agent_v2] max_concurrent_threads_per_session = 1000 manually.
4. Run a normal read-only Codex initialization surface such as codex plugin list or start another session.
5. Observe that the migration writes the 1000-thread override back.

Disabling CodeGraph alone stopped new graph workers but did not make removal of the concurrency override durable. Disabling the owning OMO plugin, removing the override, and restarting Desktop stopped both the rewrite and the hook/MCP fan-out.

Runtime toggle evidence

With OMO enabled and the 1000-thread override present:

• App server descendants: 345
• OMO-related processes: 174
• CodeGraph: 29 per-session sets / 116 processes
• OMO working set: 6274.6 MB
• Exact no-tool prompt wall time: 25179 ms

After disabling OMO, removing the override, and restarting Desktop:

• App server descendants: 13
• OMO / CodeGraph / OMO LSP / OMO Git Bash processes: 0
• Same exact no-tool prompt: 7110 ms, then 4347 ms
• Both probes exited 0, returned the exact expected text, and reported non-zero token usage.
• Re-running codex plugin list and codex features list no longer recreated the override.

Actual nested expansion observed

I reconstructed the authoritative thread_spawn_edges table and verified each maximum-depth chain against the raw rollout session_meta.source.subagent.thread_spawn object.

During the LazyCodex-enabled window (2026-07-13 09:17:32-11:34:09 KST), Codex created 39 subagent threads:

• depth 1: 31
• depth 2: 3
• depth 3: 5
• observed maximum depth: 3

One verified chain was:

root
└─ Harvey   depth 1
   └─ Curie   depth 2
      └─ Meitner   depth 3

The installation/diagnostic root itself spawned five direct depth-1 agents during this window. The depth-3 expansion occurred in another active root under the same global config. This does not mean the value 1000 automatically created those agents; it shows that the forced cap removed the normal safety boundary while real nested fan-out was occurring.

Source confirmation and ownership

Current LazyCodex main is still commit f39306f1adab6ff155fd736cc7376d27156472bc / plugin version 4.17.0:

• hard-coded value: subagent-limit-guard.mjs#L5
• unconditional call: #L38
• create/overwrite writer: #L81-L90

Upstream Codex 0.144.1 defines the stock MultiAgentV2 concurrent-session cap as 4; LazyCodex raises it to 1000. Codex Desktop's per-chat MCP lifecycle amplifies the resource impact, but the forced configuration mutation and rewrite are owned by LazyCodex.

Suggested verification criteria for a fix

• A clean install does not write max_concurrent_threads_per_session without explicit user opt-in.
• An absent or hand-removed key stays absent across SessionStart/bootstrap runs.
• Existing user values are preserved rather than overwritten.
• Windows-native bootstrap tests cover the no-write/preserve behavior.
• A GPT-5.6 Sol regression test verifies that LazyCodex leaves the stock V2 cap in effect by default.

---

This issue or PR was generated by LazyCodex.
Tag: lazycodex-generated