ChatGPT macOS 客户端 Chat 模式消失、附件传不上去怎么排查
ChatGPT 与 Codex 合并成同一个 macOS 客户端后，不少用户遇到 Chat 模式入口消失、被固定在旧界面、附件上传大概率失败等问题，重装也无效。本文拆解这几类症状背后的本地残留、服务端灰度和网络通道三种原因，给出一套可操作的完整卸载、重装与验证清单，并对比网页版、PWA、客户端分工等替代方案。
问题背景
OpenAI 把 ChatGPT 和 Codex 合并进同一个桌面客户端之后，一部分 macOS 用户的体验不是变好，而是直接退化了。典型表现是：界面被固定在合并前的旧版，左上角只显示 Codex 或 Work，侧边栏里全是 Agent 的历史记录，完全找不到切回普通 Chat 的入口；即使通过注销再登录短暂回到新界面、Chat 入口也回来了，重启应用后又有很大概率被分回旧版。
与此同时，附件上传长期不稳定：同一个文件在网页版和老版 Classic 客户端都能正常传，唯独新版客户端几乎必然失败。再加上 Classic 分支自新版推出后基本停更，常用的 thinking 档位用不了，用户就陷入一个两头堵的处境——新版 Chat 用不了，旧版 thinking 用不了，只能退回浏览器。
这类问题难排查，是因为它看起来像同一个 bug，实际上至少混杂了三种不同性质的原因。下面按“先排除本地、再判断服务端、最后换路径”的顺序拆开讲。
先分清三类症状与成因
| 症状 | 更可能的原因 | 快速判断方式 |
|---|---|---|
| 左上角只剩 Codex/Work，没有 Chat 入口 | 服务端按账号、设备维度下发的灰度分组 | 注销重登能短暂恢复，重启后又变回去 |
| 界面停在旧版布局 | 服务端实验分组 + 本地缓存了旧状态 | 清空本地配置后仍复现，基本可判定为服务端 |
| 附件上传大概率失败 | 上传走独立通道，代理规则、HTTP/3 或大文件分片被中断 | 网页版传同一个文件正常，客户端失败 |
| 老版客户端 thinking 不可用 | 老分支停止功能更新 | 只在旧客户端出现，网页版正常 |
关键判据是对照组：网页版和老客户端在同一网络、同一账号下是否正常。如果正常，账号和网络大方向没问题，问题落在客户端这一层；如果清空本地状态后依旧复现，那大概率不在你这边。
第一步：做一次真正的完整卸载
把应用拖进废纸篓几乎等于没卸载。偏好设置、容器目录、缓存和 CLI 的配置目录都会留下来，新版启动时读到旧状态，仍然可能被锁在原来的界面里。
先彻底退出进程：
osascript -e 'quit app "ChatGPT"' 2>/dev/null
pkill -f ChatGPT 2>/dev/null
然后按实际存在情况，逐项清理（不同安装方式路径略有差异，删之前建议先备份）：
/Applications/ChatGPT.app~/Library/Application Support/下与应用同名的目录~/Library/Caches/下的应用缓存目录~/Library/Preferences/下对应的.plist~/Library/Containers/下的沙盒目录（App Store 版本常见）~/Library/Saved Application State/下的.savedState~/.codex
这里有个容易漏的点：只按 chatgpt 关键字搜索会漏掉 Codex 相关的目录，而两者现在共用同一套登录态和配置。如果 ~/.codex 里存着你在意的会话或配置，先复制一份再删。
清理完成后重启一次系统，再用包管理器安装最新版，避免拿到旧的安装包缓存：
brew search chatgpt # 先确认 cask 名称
brew install --cask <对应名称>
如果这一步之后问题依旧（不少人的实测结果就是这样），说明本地已经干净，可以停止在卸载上继续投入时间。
第二步：把网络因素单独隔离出来
附件上传和普通的对话请求往往不是同一条链路：文本走长连接，上传可能是分片、多段或独立域名，代理规则里只放行了前者，就会出现“能聊天、传不了文件”的诡异现象。可以按下面的顺序试：
- 启动即全局。登录和首次加载时切到全局模式，进入正常界面后再切回规则模式，避免初始化请求被分流规则拦掉。
- 换代理模式。如果客户端支持 TUN/增强模式，试一次；部分代理对 HTTP/3（QUIC）处理不好，大文件上传容易中途失败。
- 做对照实验。同一个文件分别用网页版和客户端上传，记录失败发生在选择文件、进度条中途还是最后确认阶段，这个细节对提 issue 很有价值。
- 换网络验证。切到手机热点再试一次，能快速区分是本地网络环境还是账号侧的问题。
如果折腾完网络依然只有客户端失败，那基本可以确认是客户端自身逻辑或服务端下发状态的问题，不是你配置错了。
第三步：确认是服务端灰度后的应对方式
“注销重登能回到新界面、重启又变回去”这个特征，几乎可以认定客户端 UI 和功能入口是由服务端按账号或设备维度分配的，本地怎么重装都改变不了分组结果。能做的事情有限但有效：
- 截图提 issue。把旧界面的侧边栏、左上角入口、版本号、系统版本一起截下来，提交到官方反馈渠道或开源仓库。灰度错乱属于典型的状态不一致问题，带上复现步骤（重启几次后复现）比只写“用不了”有用得多。
- 别在灰度上死磕。这类分组会在服务端调整，用户侧没有可靠的自救手段，每天手动更新客户端当抽奖，性价比很低。
- 把两件事拆开。日常问答走网页，重活走客户端里的 Agent，不要强求一个入口解决全部需求。
替代方案怎么选
| 方案 | 优点 | 代价 |
|---|---|---|
| 浏览器网页版 | 模型和功能通常最新，不受客户端 bug 影响 | 关掉再开要刷新，不继承系统能力 |
| 网页版装成 PWA | 有独立窗口和 Dock 图标，可设快捷键呼出 | 本质还是网页，跨应用协作受限 |
| 客户端只跑 Codex | 本地文件和命令行上下文顺手 | Chat 功能等于放弃 |
| 远程 Mac 常驻 | 网络环境稳定，可长期在线跑 Codex 等工具 | 需要额外成本，交互有轻微延迟 |
PWA 的做法很简单：在浏览器里打开对话页面，选择“安装”或“添加到程序坞”，之后用系统快捷键或启动器呼出，体验接近原生客户端，网络报错丢草稿的问题也比桌面客户端少。但如果你的工作流依赖客户端调用本地应用（比如和备忘录、文件系统联动），网页和 PWA 都补不上这块，只能等客户端修复。
对于需要长时间挂着 Agent 干活、而本地网络又不太稳定的人，把运行环境放到一台长期在线的机器上是另一种思路，例如整台 Mac mini 放在新加坡机房、按月租用、远程连接使用的新加坡独享远程 Mac，本地客户端怎么抽风都不影响那边跑任务。这属于可选项，不是这个问题的必需品。
注意事项
- 清理配置前先备份
~/.codex和会话记录，删除容易恢复难。 - 不要为了绕过登录异常去买号、借号或共享账号，账号安全和封禁风险都由使用者承担。
- 客户端版本更新频繁，具体路径、菜单名称和功能开关请以官方最新发布说明为准，本文的操作步骤按实际安装情况取舍。
- 如果问题只出现在公司网络或特定代理下，优先怀疑出站规则，而不是客户端。
小结
排查顺序可以归纳成一张清单：
- 用网页版做对照，确认账号本身正常；
- 完整卸载（含
~/.codex和 Library 下的残留）后重装一次； - 启动时用全局代理，检查上传链路和 QUIC；
- 仍然复现就判定为服务端灰度，截图提 issue，停止反复重装；
- 日常问答切网页或 PWA，重活留在客户端，必要时把长任务放到远程常驻机器上。
合并后的客户端还在快速迭代，多数此类问题会随着版本推进自行消失，但在此之前，把工作流拆成“网页讨论 + 客户端执行”两段，是目前最省心的做法。
