Codex CLI 长任务完成后没有弹出通知，可能是外部 `notify` 程序没有执行，也可能是 TUI notifications 被关闭、终端不支持所选提醒机制，或窗口仍处于前台而条件设为 only unfocused。外部通知脚本与 TUI 内建提醒属于两套入口：前者由 Codex启动指定程序，后者通过 OSC 9 或 BEL 等终端能力发出提示。先确认你使用的是哪一种，才能避免在错误配置段里反复修改。

一、区分外部 notify 与 TUI notifications

顶层 `notify` 通常是一个 argv 数组，用来调用本机通知程序或自定义脚本。它适合把完成事件转成桌面弹窗、声音或团队内部提醒。`[tui] notifications` 则控制终端界面的通知事件，可以整体开启关闭，也可以只选择任务完成或请求审批等事件。

两者可以同时存在，也可以只启用一种。外部脚本没运行时，先检查 `notify`；终端没有提示时，检查 `[tui]`。不要把 `notifications = false` 写在顶层，也不要把 `notify` 误写进 `[tui]` 表中。

二、先在终端手工运行通知程序

把配置中的可执行文件和参数原样拿到同一终端测试。Linux 常见通知程序、macOS 脚本和 Windows PowerShell 的实现不同。若手工运行都没有通知，问题在操作系统权限、程序路径或桌面会话，不在 Codex。

使用系统命令查找可执行文件的真实路径。Codex子进程不一定读取你的 shell alias 或 profile，短命令在人工终端能用，后台调用却可能找不到。团队脚本应使用稳定路径，并避免依赖交互窗口。

三、notify 必须写成参数数组

外部通知配置应把程序和每个参数分开，不要把整条 shell 命令塞成一个字符串后指望自动解析。路径带空格时，数组结构能减少引号问题。需要复杂逻辑时，把逻辑放进单独脚本，配置只负责调用脚本入口。

脚本应快速返回，不能等待键盘输入。先把收到的事件写入脱敏临时日志，确认 Codex确实调用了它，再接桌面通知。调试结束后删除日志或设置轮转，避免长期记录项目名称和任务信息。

四、检查配置层级与信任状态

通知程序属于机器本地行为，通常应放在用户级配置，而不是随仓库共享。项目配置可能不允许覆盖某些通知或遥测类键。你修改了 `.codex/config.toml` 却没有效果时，检查该键是否只接受用户层设置。

同时确认启动时选用的 profile。一个 profile 关闭通知，另一个开启，表现会随命令参数变化。使用配置诊断查看最终值，比只读某一个文件更可靠。

五、核对 TUI notifications 事件过滤

`[tui] notifications` 可以是布尔值，也可以只列出指定事件。若列表里只有 approval-requested，普通任务完成自然不会提醒。先临时开启全部通知做测试，成功后再收窄到真正需要的事件。

事件过滤要使用当前文档支持的名称，拼写错误不会变成近似匹配。修改后重新启动 TUI，并运行一个短任务和一次低风险审批，分别确认两类事件。

如果大家想体验一线 AI 编程模型 codex 和 claude，用它们完成长任务、代码修改和自动提醒，可以参考以下教程文档进行接入配置，接入配置好后即可使用。文档教程：https://my.feishu.cn/wiki/NIgLwuuj1ibzJIkLGM0cgVNinzg

六、notification_condition 可能让前台测试失效

默认条件通常只在终端未聚焦时提醒。你一直盯着当前窗口等待弹窗，任务完成后没有通知，可能正是配置按预期工作。测试时启动任务后切换到其他窗口，或者临时把条件设为 always。

确认后再决定长期策略。always 容易在频繁短任务中产生通知疲劳；unfocused 更适合只在离开终端时提醒。团队不要强制所有人使用同一焦点条件，桌面习惯差异很大。

七、notification_method 要匹配终端能力

TUI 可以自动选择提醒机制，也可明确使用 OSC 9 或 BEL。不同终端、tmux、SSH 和 IDE 集成终端对这些协议支持不同。BEL 可能只发声音或闪烁，OSC 9 可能被终端设置禁用。

先使用 auto，再查看终端通知权限。Windows Terminal、VS Code、远程 SSH 和容器内终端的宿主不同，通知往往由本机终端处理，而不是远程服务器。远程环境里外部 notify 程序可能根本没有桌面会话。

八、操作系统通知权限也要检查

系统的专注模式、免打扰、应用通知权限和后台权限都可能吞掉提醒。让通知脚本直接触发一条测试消息，检查系统通知中心是否有记录。若通知中心有消息但没弹窗，调整系统展示方式即可。

不要为了通知给脚本管理员权限。桌面提示通常不需要高权限。企业电脑若由策略禁用通知，应遵守管理规则，改用终端声音或明确的任务列表。

九、脚本收到事件却解析失败怎么办

Codex 可能向通知程序传递结构化事件参数。自定义脚本若假设参数永远固定，版本变化后可能崩溃。先把参数数量、类型和必要字段做宽容校验，未知字段忽略，缺失字段使用安全默认值。

脚本异常时返回清楚退出码，并把错误写入本地诊断日志，不要把秘密或完整提示内容发到第三方通知服务。对 webhook 类通知还要设置超时，避免一个提醒接口拖慢会话结束。

十、建立最小通知验收流程

依次验证：通知程序手工可用、Codex能找到程序、notify 数组正确、配置层级生效、TUI 事件已开启、焦点条件满足、终端协议受支持、系统权限允许。每次只改一项并重新测试。

最后用一个几秒钟的任务和一次审批请求做双重验证，记录哪个入口产生了提醒。稳定方案不需要最复杂，能明确知道“谁触发、谁显示、失败看哪里”，就足以让长任务通知可靠运行。