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

[0xdeafbeef]

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

[0xdeafbeef]

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

[jif-oai]

#12105

[0xdeafbeef]

#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]

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