`spawn_agent` hides root cause as "not found"; forward underlying I/O error to model

Resolved 💬 4 comments Opened Feb 17, 2026 by 0xdeafbeef Closed Feb 24, 2026
💡 Likely answer: A maintainer (jif-oai, contributor) responded on this thread — see the highlighted reply below.

What version of Codex CLI is running?

codex-cli 0.102.0-alpha.4

What subscription do you have?

not applicable

Which model were you using?

_No response_

What platform is your computer?

_No response_

What terminal emulator and version are you using (if applicable)?

_No response_

What issue are you seeing?

Codex can't spawn subagents when inotifies are exhausted and doesn't forward error to model/user.

### User-visible symptom
Agent spawned
└ call: call_xmnq4AwNgAiZ55mkavinJAF7
agent: not created
status: not found

I waited and retried; still blocked by agent thread limit reached (max 6).
If you can close/free one agent slot, I’ll launch it immediately.

### Relevant logs (~/.codex/log/codex-tui.log)

  2026-02-17T15:19:37.551413Z  INFO ... ToolCall: spawn_agent ... thread_id=019c68ae-0475-7c63-a751-
  382f2d5cc2cc
  2026-02-17T15:20:54.162653Z  INFO ... ToolCall: spawn_agent ... thread_id=019c68ae-0475-7c63-a751-
  382f2d5cc2cc
  2026-02-17T15:21:55.660754Z  WARN codex_core::thread_manager: failed to initialize file watcher:
  No file descriptors available (os error 24)
  2026-02-17T15:22:22.695504Z  WARN codex_core::thread_manager: failed to initialize file watcher:
  No file descriptors available (os error 24)

What steps can reproduce the bug?

Exhaust inotify watchers, get opaque error instead of actionable out of inotify close something or bump limit

What is the expected behavior?

_No response_

Additional information

019c68ae-0475-7c63-a751-382f2d5cc2cc

View original on GitHub ↗

4 Comments

0xdeafbeef · 6 months ago

In my case it was exhaustion of fs.inotify.max_user_instances while were not fully used
inotify.max_user_watches

jif-oai contributor · 6 months ago
0xdeafbeef · 6 months ago
https://github.com/openai/codex/pull/12105

Also would be nice to forward real io errors to agent to make situations when some resource is exhausted / something is broken easier to debug

jif-oai contributor · 6 months ago
Also would be nice to forward real io errors to agent to make situations when some resource is exhausted / something is broken easier to debug

@0xdeafbeef actually I thought about it and I think we should forward the error to the user but not the agent. Otherwise the agent might try to solve it itself by just closing random inotify. In general I prefer give only the relevant context to the agent to prevent it from trying random stuff