[bug] `!<cmd>` output invisible to Codex (defeats the entire Product UX purpose of the feature)
What version of Codex is running?
codex-cli 0.52.0
What subscription do you have?
API Key
Which model were you using?
gpt-5-codex high
What platform is your computer?
Darwin 25.0.0 arm64 arm
What issue are you seeing?
Current behavior:
Running !ls or !tree in Codex terminal executes, but Codex sees nothing.
Why this breaks the UX:
If I just wanted to run commands, I'd use a separate terminal. The entire product purpose of !cmd is collaborative execution: showing the agent both inputs + outputs (e.g., exploring a codebase together).
Impact:
Can't collaborate with Codex without copy-pasting everything manually.
What steps can reproduce the bug?
<img width="523" height="200" alt="Image" src="https://github.com/user-attachments/assets/0e0c066d-26ae-49a9-a344-7637e7b28e6a" />
What is the expected behavior?
<img width="746" height="162" alt="Image" src="https://github.com/user-attachments/assets/efea1ba3-30ca-4aff-90ff-06cd8702b0b2" />
Additional information
Labeling this as a design-level bug. While the “bug” label is usually used for implementation issues, the current behavior represents a break in the product’s intended UX design.
3 Comments
This one is pretty important to me too. One of my typical use cases is to kick off a lint via a command like
!yarn lint. If I see that any issues were returned i could tell the LLM to work on those issues. It adds quite a bit of utility being able to directly get the output of the command into context then act on it.This is WAI we currently don't inject output in the conversation history. We are having discussions around this. Closing this for now.
The workflow you've left us with:
So !cmd saves us... nothing. Arguably costs us, because nothing in the UI signals that the agent is blind to the output.
The feature only makes sense if the loop closes. Otherwise it's a shell escape that looks like integration but isn't. Worse than not having it, because it sets an expectation it doesn't fulfill.
"WAI" on this is essentially admitting the feature is decorative.
Proposal
Suggested behavior:
This preserves the current default while enabling the collaborative workflow that makes the feature useful. Minimal surface change, clear mental model.