In OpenAI’s openai/codex repository, the public commit #35029 adds optional plugin_id and script_path fields to command-approval and Guardian-assessment events. A command approval is a tiny moment of delegated power: someone or something asks to run a command, and a person decides whether it may proceed. If the record preserves only the command string, that person can inspect what will run—but not necessarily what extension brought the request to the boundary in the first place.
OpenAI Codex has just made that missing provenance an explicit source-level concern. Its public plugin-attribution change adds optional plugin_id and script_path fields to approval and Guardian-assessment events, then carries them through delegated approvals, command items, app-server notifications, thread history, and rollout traces. The point is not that a plugin becomes suspicious by default. It is that an approval has more meaning when the system retains who asked for it.
What gets lost after the first prompt
The first angle was a UI polish story: name the plugin in an approval dialog, make the choice feel clearer. The diff made that too small. In Codex’s approval protocol, the new fields join the event itself. The app server then keeps them when it turns an approval request into an active command item and again when it completes that item. The thread-history tests explicitly rebuild a command from persisted events with a sample plugin and script path intact.
That persistence matters because an approval decision is not one frame of a chat. It can be delegated for review, declined, completed, reconstructed from history, or written to a trace. A source that survives only the initial request leaves an operator with a misleadingly clean later record: a command occurred, but the initiating capability has vanished. Codex’s change keeps the two identifiers on both started and completed command items, including declined commands, rather than letting the audit trail begin after the important question was asked.
Review needs provenance too
Guardian-reviewed commands are where the distinction becomes sharper. The inspected app-server handling copies plugin attribution from the Guardian assessment into the command-execution item. Its companion history tests exercise that handoff for commands under review as well as legacy completion reconstruction.
For a user, this changes the practical question from “is this shell string acceptable?” to “is this shell string acceptable from this plugin, at this script path, through this review lane?” Those are not interchangeable questions. The same command can be routine inside one installed capability and a surprise if it arrives through another. Retaining the origin does not decide consent for the user; it makes the decision inspectable at the moment and later.
An audit trail is a chain, not a label
The transferable design lesson is unglamorous: give a consent-sensitive request a stable provenance record, validate it at the boundary, and propagate it through every state transition that a user or operator may later rely on. Test the refusal path as carefully as the successful one. A system that remembers the plugin only while a modal is open has built a label, not an audit trail.
The sources do not show how every Codex client renders these optional fields, whether a released build includes the change, or whether the fields prevent a malicious plugin from requesting a command. They do show a more honest foundation for the next user-facing decision: a command approval can now retain the tool that asked for power long enough for someone to judge it.