for notify feature, the "input_messages" does not update

What version of Codex is running?

(v0.45.0)

Which model were you using?

gpt-5-high

What platform is your computer?

macos

What steps can reproduce the bug?

Bug Report: Codex CLI Notify Integration Field Name Mismatch

Summary

The Codex CLI notify integration uses a different field name for the input messages list than what the documentation shows. This causes scripts implemented per the docs to fail to read the input messages and leads to stale or empty content in notifications.

Expected Behavior

The documentation and the actual JSON payload should use the same key for the input messages list so that a script implemented from the docs works as-is.

Actual Behavior

• Documentation examples use input_messages (snake_case)
• The actual JSON payload sent by Codex contains input-messages (kebab-case)
• Scripts written per the docs that read notification.get("input_messages", []) won't see the messages, so notification titles/bodies are wrong or appear to "stick" to a previous value

How to Reproduce

1. Configure notify in ~/.codex/config.toml, e.g.:

``
notify = ["python3", "/Users/<USER>/.codex/notify.py"]
``

1. Implement notify.py using the docs' example:

``python
input_messages = notification.get("input_messages", [])
``

1. Use Codex normally; when notify fires, observe your script's output/logs:

• input_messages is empty or doesn't update, even though turns clearly have user input

Evidence

• Doc snippet (notify section) reads:

``python
input_messages = notification.get("input_messages", [])
``

• Runtime JSON emitted by the CLI uses:

``json
"input-messages": ["..."]
``

• A robust version of notify.py needs to do:

``python
input_msgs = notification.get("input_messages") or notification.get("input-messages") or []
``

Impact

Anyone following the docs will fail to read the user's input list from the notify JSON. This leads to:

• Incorrect titles/bodies
• The impression that Codex is not updating input messages across turns

Suggested Fix

Documentation Fix (Preferred, Low Risk)

• Update examples to use input-messages to match the emitted payload

CLI Compatibility (Optional, Requires Evaluation)

• If the canonical key will be input_messages, consider emitting both keys for one deprecation cycle
• Announce the transition and timeline in release notes

Alternative Approach

• Explicitly document both keys and provide a compatibility snippet:

``python
input_msgs = notification.get("input_messages") or notification.get("input-messages") or []
``

• Note which key is canonical going forward

Backward Compatibility and Risk

• Docs-only update: no breaking changes, minimal risk
• Dual-key emission: most compatible; slightly larger payload; needs a deprecation plan
• Changing the emitted key outright: potentially breaking; requires a transition period and clear communication

Environment

• macOS, Codex CLI (TUI + external notify)
• notify configured via config.toml
• Downstream notifier (terminal-notifier/osascript) is not implicated; the issue is the JSON field name

Conclusion

The mismatch between the docs and the actual JSON field name is the root cause. Please align the documentation with the emitted payload or temporarily emit both keys to avoid breaking scripts written from the docs.

What is the expected behavior?

_No response_

What do you see instead?

_No response_

Additional information

_No response_