Codex CLI v0.115.0 has serious output corruption issues with sub-agents

What version of Codex CLI is running?

v0.115.0

What subscription do you have?

Pro

Which model were you using?

gpt-5.4 high and gpt-5.4-mini medium

What platform is your computer?

Microsoft Windows NT 10.0.19045.0 x64 - wsl: Linux 5.10.102.1-microsoft-standard-WSL2 x86_64 unknown

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

Windows Terminal

What issue are you seeing?

For some reason, sometimes agents spawned do not report correct status, at all. Here's an example:

Implementing CT. • I have the approved boundary and the Scope ID: 92e54653890425b-e57942dbd8b. Next I’m starting CT-TP-005 in the tracker, then I’ll inspect the tuple/reference implementation seams and map the smallest viable change that stays out of generated visitor and ExpressionKind scope. • The current seams are exactly where expected: IBoundember and/property chaining depends on IMemberParentReferenceExpression. I’m reading the tuple projection types and nearby reference-expression implementations now to find a shape that composes cleanly without forcing visitor or. • ’ve confirmed the tension the new node needs to behave like an existing member-parent reference for chaining, but honestly surface a logical element asember. I’m checking IBoundMember.Member` is consumed so I relax that in safe way rather than forcing a fake member or visitor scope.

Background tasks don't seem to report properly for these agents. I see a constantly climbing figure:
11 background terminals running · /ps to view · /stop to close

What steps can reproduce the bug?

Ask the main agent to spawn a specific agent of a specific model type and reasoning level.

What is the expected behavior?

Implementing CT-TP-005 inside the approved write set. I'm reading the approval frame, task spec, and baseline AST files first so I can execute the exact approved commands and keep the change bounded. I have the approved boundary and the Scope ID created locally: 92e54653-890b-4d12-b25b-e57942db1d8b. Next I'm starting CT-TP-005 in the tracker, then I'll inspect the tuple/reference implementation seams and map the smallest viable change that stays out of generated visitor and ExpressionKind scope. The current seams are exactly where expected: IBoundMemberReference assumes a real IMember, and field/property chaining depends on IMemberParentReferenceExpression. I'm reading the tuple projection types and nearby reference-expression implementations now to find a shape that composes cleanly without forcing visitor or enum changes. I've confirmed the core tension: the new node needs to behave like an existing member-parent reference for chaining, but it cannot honestly surface a logical tuple element as an IMember. I'm checking where IBoundMemberReference.Member is consumed so I can relax that contract in the smallest safe way rather than forcing a fake member or widening visitor scope.

Retrieved this by asking the agent what it was supposed to have written, and this is what it wrote to a file.

Additional information

It's almost as if these separate agents are skipping incoming packets/frames or something and you're receiving a partial stream. I'm also not seeing it launch specific commands, just a silently increasing command list that /stop doesn't fix.