Codex 通知怎么设置？桌面提醒、TUI notifications、notify 与审批提示指南

先说结论：完成提醒与审批提醒要分开配置

桌面应用可以控制任务完成、权限和问题通知；终端 TUI 可通过 tui.notifications 接收 agent-turn-complete 或 approval-requested；需要调用系统脚本、Webhook 或 CI 通道时，再使用用户级 notify。

外部 notify 当前支持的事件以 agent-turn-complete 为主，不应把它当成所有审批事件的通用替代。需要及时回应命令审批时，应保留桌面或 TUI 的 approval-requested 通知。

本站为第三方中文信息与服务入口，并非 OpenAI 官方。事件名称、配置键和渠道可能更新，请以 ChatGPT Learn 官方文档、当前 Codex 版本及系统通知权限为准。

一、先确定你真正需要哪种提醒

任务完成提醒适合长测试、代码审查和批处理；审批提醒用于 Codex 等待命令或权限决定；问题提醒用于模型需要用户补充信息；活动列表则适合同时跟踪多条聊天。

把所有渠道全部打开会产生噪声。建议先选择一个主要完成通知和一个审批通知，再根据漏报或重复情况调整。

二、桌面应用通知在哪里设置

在 ChatGPT 桌面应用 Settings 中，可选择任务完成提醒从不显示、仅应用在后台时显示，或始终显示；权限与问题通知有独立开关。

第一次启用时，操作系统可能要求授予通知权限。应用内已经打开但系统级权限被禁用，仍然不会出现桌面横幅。

三、怎样用 Activity 视图跟踪多条聊天

桌面端支持 Activity 时，可点击侧边栏铃铛查看未读、运行中或等待回复的聊天。macOS 可用 Cmd+Option+U，Windows 可用 Ctrl+Alt+U 打开或关闭。

根据当前界面，筛选项可能包含 Work、Chat、Pinned 和 Scheduled。Activity 适合集中查看状态，但它不是系统推送权限，也不会替代审批策略。

四、网页通知与桌面通知不是同一层

网页端可在 Settings > Notifications 管理账号可用的通知类别和渠道；不同账号与类别可能支持推送、邮件或短信。定时任务相关设置还可通过 Manage tasks 进入 Scheduled。

浏览器、操作系统和账号设置都可能影响最终送达。排查时应分别检查站点权限、系统勿扰模式和 ChatGPT 通知类别。

五、TUI notifications 适合什么场景

在终端中运行 Codex 时，tui.notifications 提供内置通知。它可以设为布尔值，也可以限制为特定事件，例如 agent-turn-complete 与 approval-requested。

只关心等待审批时，可只保留 approval-requested；长任务结束需要回到终端时，可启用 agent-turn-complete。精确筛选比无差别提醒更不容易形成通知疲劳。

六、notification_condition 控制什么时候提醒

tui.notification_condition 可设为 unfocused 或 always。unfocused 表示终端没有焦点时提醒，适合避免正在看终端时重复弹窗；always 则无论焦点状态都尝试发出通知。

官方配置参考显示默认值为 unfocused。若你一直盯着终端测试通知，可能误以为功能失效，先检查是否只是焦点条件没有满足。

七、OSC 9、BEL 和 auto 有什么区别

tui.notification_method 支持 auto、osc9 或 bel。auto 会优先使用终端可能识别为桌面通知的 OSC 9，不支持时回退到 BEL 提示音或终端铃。

不同终端对 OSC 9 和 BEL 的支持差异很大。没有横幅时，先用 auto，再检查终端通知设置；不要只根据是否有声音判断事件有没有产生。

八、外部 notify 与 TUI 通知的区别

notify 会在 Codex 发出支持事件时运行一个外部程序，适合调用系统通知工具、团队 Webhook 或 CI 更新；tui.notifications 则由终端界面直接处理，不需要额外脚本。

官方当前说明，外部 notify 主要支持 agent-turn-complete。它不是 Hooks，也不是审批机制，不能因为配置了完成通知就关闭必要的命令审核。

九、notify 命令怎样写

在用户级 config.toml 中可配置类似 notify = ["python3", "/path/to/notify.py"] 的命令数组。事件发生时，Codex 会把一段 JSON 作为单个参数传给脚本。

常见字段包括 type、thread-id、turn-id、cwd、input-messages 和 last-assistant-message。脚本应先检查 type，再生成简短通知，不要直接把完整输入发送到不受控的外部服务。

十、为什么 notify 应放在用户级配置

外部通知会执行机器上的程序，属于个人设备与主机级行为。项目内 .codex/config.toml 的 notify 设置会被忽略，应放在用户级 ~/.codex/config.toml 或 Windows 的 %USERPROFILE%\.codex\config.toml。

如果不同任务需要不同通知程序，可结合独立 Profile 管理。Profile 配置方法见 https://gptupcn.com/blog/codex-config-profiles-toml-cli-override-migration-guide-20261007/ 。

十一、IDE 扩展为什么没有单独通知开关

官方说明，IDE 扩展不提供独立通知控制；需要跟踪活动时应保持聊天可见。若要在完成时运行外部程序，应在连接的 Codex 主机上配置 notify。

远程或 SSH 场景尤其要确认脚本究竟运行在哪台主机。通知程序、Python 路径和系统通知工具必须在实际执行 notify 的机器上存在。

十二、通知脚本的安全与隐私

通知 JSON 可能包含工作目录、输入消息和最后一条助手回复。发送到团队聊天或 Webhook 前，应做字段白名单、长度限制和脱敏，避免泄露代码、客户名称、路径或任务内容。

脚本路径应固定且只允许可信用户修改；网络目标应限制到必要域名。通知失败不应阻断核心任务，也不应把密钥写入脚本、config.toml 或日志。

十三、没有通知时的排查顺序

先确认任务确实产生对应事件；再检查应用或 TUI 配置、系统通知权限、勿扰模式、终端对 OSC 9/BEL 的支持、notification_condition 的焦点条件，以及外部脚本路径与执行权限。

使用 /debug-config 确认最终配置来源，避免被 Profile 或更高优先级覆盖。审批与沙箱说明可参考 https://gptupcn.com/blog/codex-cli-permissions-sandbox-approval-policy-guide-20260924/ 。

十四、推荐的最小通知方案

桌面工作：开启后台完成提醒、权限与问题提醒，并用 Activity 查看多聊天状态。终端工作：启用 agent-turn-complete 与 approval-requested，条件先用 unfocused，方法先用 auto。

只有确实需要跨系统通知时再配置外部 notify，并只发送任务 ID、状态和简短摘要。更多 Codex 中文实践可从 https://gptupcn.com/ 的技术博客进入。

十五、上线前怎样测试通知链路

先用一个不涉及敏感数据的短任务测试完成通知，再发起一个需要批准的安全命令测试审批提醒。测试时分别让终端保持焦点和失去焦点，确认 unfocused 条件是否符合预期。

外部 notify 脚本应先在命令行单独运行，检查 JSON 解析、退出码、超时和失败日志；随后再由 Codex 触发。发送到团队通道时，用测试频道验证格式和权限，不要直接对生产群组试发完整消息。

最后记录通知运行在哪台主机、由哪个配置层启用、失败是否影响任务，以及由谁维护脚本。远程主机更换或 Profile 调整后，应重新执行同一套测试。

结语

Codex 通知要按工作界面分层设置：桌面与网页负责产品通知，TUI 负责终端事件，notify 负责外部程序。把完成、审批和问题提醒分开，并控制敏感字段，才能既不错过任务，又不制造噪声或泄露信息。