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 事件已开启、焦点条件满足、终端协议受支持、系统权限允许。每次只改一项并重新测试。最后用一个几秒钟的任务和一次审批请求做双重验证记录哪个入口产生了提醒。稳定方案不需要最复杂能明确知道“谁触发、谁显示、失败看哪里”就足以让长任务通知可靠运行。
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 事件已开启、焦点条件满足、终端协议受支持、系统权限允许。每次只改一项并重新测试。最后用一个几秒钟的任务和一次审批请求做双重验证记录哪个入口产生了提醒。稳定方案不需要最复杂能明确知道“谁触发、谁显示、失败看哪里”就足以让长任务通知可靠运行。
