看到 Claude Code 提示进程以 code 1 退出，不要马上卸载、清缓存或删除配置。这个提示只说明 Claude Code 启动出来的进程以通用失败码退出了，还没有告诉你失败归属。正确的第一步是确认它发生在哪个启动入口：普通终端、VS Code/Cursor、Claude Desktop/Cowork、脚本/CI、旧会话，还是登录和状态路径。
先用分支板定归属
退出代码 1 是症状，不是诊断。它可能发生在请求到达 Anthropic 之前，也可能来自 IDE 启动的子进程、shell 初始化文件、hook、npm 脚本、登录状态、Windows PATH、一次版本更新或服务状态。中文开发者讨论里常见的快速答案会把它直接归为 Desktop 版闪退、API key 未设置、缓存损坏或 VS Code 插件问题；这些都可能是某一条分支，但不能直接覆盖全部场景。
先按下面这张表选分支。不要同时执行多条修复，否则下一次成功或失败都无法说明原因。
| 你看到的现象 | 第一归属分支 | 最安全的第一步 | 如何验证 | 何时升级 |
|---|---|---|---|---|
| 普通终端直接失败 | 终端启动或安装路径 | 在项目目录打开全新 shell，再运行 claude doctor | 回到同一条命令复测 | 新 shell 和 doctor 仍指向同一失败 |
| 只在 VS Code、Cursor 或集成终端失败 | IDE 子进程 | 到系统原生终端跑同一命令 | 对比 IDE 与原生终端结果 | 原生终端正常但 IDE 仍失败 |
| 登录、换账号、订阅/API key 切换后失败 | 认证或会话 | 先看 /status，只刷新当前路径的登录 | 同一路径重新登录或启动 | 状态正常但认证路径仍失败 |
| Windows 提示找不到命令、Git、shell 或 PATH 异常 | 安装和 PATH | 查 where claude、git --version、PATH 顺序 | 新终端找到预期 binary | 前置检查通过但启动仍退出 |
| 通过 npm、hook、alias、CI 或任务脚本失败 | wrapper 或脚本 | 绕过外层脚本，直接运行底层 claude | 一层层加回 wrapper | 直接命令正常、wrapper 复现失败 |
| 只有某个旧会话或项目失败 | 会话状态 | 新建最小会话或临时目录 | 运行最小同类任务 | 新会话也同样失败 |
| 更新后大量人同时报错或状态页异常 | 版本或服务状态 | 记录版本和状态检查时间 | 等状态或版本变化后同路复测 | 证据包齐全后提 issue |
这张表的核心不是给你七个修复按钮，而是减少误操作。重装可能有用，但只有在安装分支成立时才是第一动作。清空配置可能有用，但在认证分支、IDE 分支或 wrapper 分支未确认前，它会破坏现场。真正的修复完成标准也不是“另一条路径能跑”，而是原来失败的同一路径在一次最小变更后恢复。
这个错误到底表示什么
这条 code 1 文案的含义很窄：某个 Claude Code 相关进程返回了通用失败码。它没有直接说明是 API 500、额度限制、网络故障、账号异常、插件崩溃还是本地脚本退出。你需要把“可见错误文案”和“实际归属”分开。
如果错误出现在 Claude Desktop 或 Cowork 入口，用户很容易把它当成桌面端本身坏了；如果出现在 VS Code 或 Cursor，用户又会直接怀疑插件；如果它在 GitHub Action 或 npm script 里出现，很多回答会把它解释成 SDK 配置问题。更稳的判断方式是看失败发生在请求链路的哪一层：启动前、认证前、IDE 注入环境、包装脚本、Claude Code 本体、网络/状态，还是 API 响应后。
排查时遵守四条规则：一次只改一个变量；保持原始启动路径不变；改完回到同一路径验证；如果同一路径仍失败，保留证据再升级。只要你同时重装、清缓存、改 PATH、换 key、关插件，就算最后好了，也很难知道是哪一步起作用。下一次再遇到同类问题，还得重新猜。
状态、认证和登录分支
当错误出现在登录、换账号、订阅/API key 切换、组织权限变化、SSO 或服务波动之后，先走状态和认证分支。不要把认证问题直接当成安装问题，也不要把状态事件当成本地配置损坏。状态是易变事实，今天 15:00 的状态页和昨天截图不是同一份证据。
实操顺序可以这样定：先查看 Anthropic 状态页，记录检查时间；如果 Claude Code 能进入交互，就运行 /status 看当前账号和路由；如果明显是登录路径，执行当前路径的 logout/login 或官方诊断命令；如果是 token、OAuth 或订阅/API key 切换，不要同时轮换所有凭据。中文用户常见的误区是把 API key、订阅账号、Claude Desktop 登录和 Claude Code CLI 登录混成一件事，它们可能互相影响，但不是同一个证据。
这里还要和相邻问题分开。如果日志已经出现明确 HTTP 500、request id 或服务端错误，应转到 Claude Code API Error 500 指南。如果问题变成 API key 与订阅计费路径的混淆，应看 Claude Code API key 与订阅计费指南。如果证据明确是使用量窗口或 rate limit，就不要让退出代码 1 页面继续吸收那个任务。
Windows、PATH 和安装分支
只有当证据指向命令找不到、Git 缺失、shell 不支持、PATH 顺序错、binary 路径混乱或权限问题时，才把它当成安装分支。单独一句退出代码 1 不足以证明 Claude Code 需要重装。
在 macOS/Linux，可以先查 claude --version、which claude 和 claude doctor。在 Windows，可以查 where claude、git --version、PowerShell/WSL/终端环境以及 PATH 顺序。若这些基础命令在全新终端里都不能跑，说明问题很可能在安装或 PATH，而不是 IDE 或会话。
如果 claude --version 正常，先不要重装。一个能输出版本的 binary，在特定项目、特定 IDE 或特定脚本里失败，通常说明归属在环境、工作目录、wrapper、auth 或会话。安装指南适合处理前置条件和安装方式；这里处理的是“进程已经被启动，但在某条路径里以 code 1 退出”。若你还没有完成安装基础检查，可以先看 Claude Code 安装指南。
IDE、环境变量和会话状态
中文和日韩开发者案例里，VS Code、Cursor、Desktop/Cowork 的讨论很多。这个分支必须认真测，因为 IDE 启动进程时可能注入环境变量、调试配置、工作目录、扩展设置或集成终端 shell。相同的 claude 命令，在系统终端和 IDE 子进程里不一定处在同一环境。
先做原生终端对比：在系统终端进入同一项目目录，运行 pwd、claude --version 和最小 claude 启动。然后在 IDE 内用同一目录和同一命令复测。如果原生终端正常、IDE 内失败，优先检查扩展输出日志、集成终端 shell、工作目录、workspace settings、debugger auto-attach、task/launch 配置和被注入的环境变量。
如果两条路径都失败，再看环境变量和会话状态。环境变量检查只应覆盖可能影响启动的部分：PATH、proxy、token/auth、shell startup、Node 或 shell shim、公司网络变量。不要打印 secrets，更不要为了“干净”删除全部凭据。会话状态则要单独测：新建一个最小会话或临时目录，运行最小任务。如果新会话正常，旧会话或项目状态就是线索；如果新会话也失败，说明问题不只是旧上下文。
Hooks、wrapper、npm 脚本和 CI
很多团队不是直接运行 Claude Code，而是通过 npm script、alias、shell function、pre-commit hook、CI step 或内部任务工具启动。外层脚本失败时，最终展示的可能仍是 “Claude Code process exited with code 1”，但真正返回 code 1 的也许是 wrapper、hook 或超时层。
测试方法很简单：先绕过 wrapper，直接运行底层 claude 命令；如果直接命令正常，再一层层加回 alias、npm script、hook、CI 环境和超时配置。第一次把错误带回来的那层，就是第一修复对象。检查它的退出码、权限、工作目录、环境变量、超时、日志重定向和依赖命令。
不要在 direct path 正常时立刻重装 Claude Code。那只是在改一个已经被证明可以工作的层。尤其是 CI 或 GitHub Action 场景，常见失败点包括缺少 secret、工作目录不一致、shell 非交互模式、权限不够、超时被外层杀掉、以及 wrapper 把 stderr 吃掉。先把 wrapper 路径收窄，再决定是否需要升级到 Claude Code 本身。
更新回归或实时事件分支
如果错误刚好出现在更新后，或者社区里同一时间出现大量相同反馈，版本/事件分支就值得保留。但它仍然需要当前证据，不能用旧帖当今天的解释。
记录这些信息：claude --version，安装来源，操作系统和 shell，IDE 及扩展版本，原生终端是否复现，Anthropic 状态页在排查时是否异常，最近是否改过登录、PATH、代理、workspace settings 或 wrapper。然后回到同一路径复测。如果状态恢复后同一路径恢复，可能是服务分支；如果只在某个版本出现，并且官方或 issue 里有对应修复，可能是版本分支；如果这些都不成立，就不要一直把锅甩给“最新版本”。
这个分支的价值在于避免无效本地折腾。服务异常期间反复清缓存、换 key、重装，只会制造更多变量。版本回归期间不记录版本号，也无法让 issue 被维护者快速定位。证据要短，但要能证明：哪条路径失败、哪条路径正常、版本和状态是什么。
同一路径验证和升级证据包
修复是否完成，只看同一路径。原本是在 VS Code 里失败，系统终端能跑只能说明系统终端分支正常；你仍然要修 IDE 路径。原本是 npm script 失败，直接命令能跑只说明 wrapper 可疑；你仍要回到 npm script 验证。
升级前收集证据包：启动方式或完整命令、完整错误文本、Claude Code 版本、操作系统/shell/IDE、状态页检查时间、当前认证路径、最近变更、原生终端与 IDE 或 wrapper 对比、最小复现步骤、日志、session id、request id 或 correlation id。如果没有 request id，也不要编一个；这可能说明请求根本没到服务端，反而是本地启动分支的重要证据。
证据包不是形式主义。维护者或支持人员最需要的是归属判断：“macOS zsh，原生终端正常，VS Code 内失败，关闭 auto-attach 后恢复”远比“Claude Code code 1 怎么办”有用。“Windows 新终端找不到 claude，PATH 指向旧目录”也比“重装无效”更可执行。
按分支快速修复
| 分支 | 先做什么 | 不要先做什么 | 成功证据 |
|---|---|---|---|
| 终端启动 | 新 shell、同目录、claude doctor | 删除全部配置 | 同一命令启动成功 |
| 认证/会话 | /status、当前路径登录刷新 | 轮换所有 token | 同一路径登录或启动成功 |
| Windows/PATH | where claude、Git、PATH 顺序 | 没证据就重装 | 新终端找到预期 binary |
| IDE 子进程 | 原生终端对比 | 全局怪 Claude Code | IDE 路径与原生终端一致 |
| 环境变量 | 查 PATH/proxy/token/shell startup | 打印或删除 secrets | 一个变量差异解释失败 |
| hooks/wrapper | 绕过 wrapper 后一层层加回 | 先改 Claude Code | direct path 正常，wrapper 复现 |
| 状态/版本 | 记录版本和状态时间 | 用旧帖当当前证明 | 状态或版本变化后同路恢复 |
| 未知 | 保留证据并升级 | 继续随机尝试 | issue 有分支证据 |
常见问题
code 1 是否代表 Claude Code 挂了？
不一定。它只说明被启动的进程失败。状态异常是一个分支，但本地终端、IDE 子进程、环境变量、hook、认证、会话和安装路径都可能给出同样的可见文案。
我应该先重装 Claude Code 吗？
通常不应该。只有当安装分支有证据，例如 binary 找不到、PATH 错、Git 或 shell 前置条件失败、权限异常或安装损坏时，重装才适合作为第一动作。如果一个路径能跑、另一个路径失败，重装多半是噪音。
最快的安全检查是什么？
先确认启动入口，再做原生终端对比。问清楚错误出现在终端、IDE、Desktop/Cowork、脚本、CI、登录还是旧会话。然后只改一项，并回到同一路径验证。
只在 VS Code 或 Cursor 里报错怎么办？
在系统原生终端同目录跑同一命令。如果原生终端正常，检查扩展日志、集成终端 shell、workspace settings、debugger auto-attach、环境变量和工作目录差异，不要直接删除全局 Claude Code 配置。
它和 Claude Code API 500 或 rate limit 是同一个问题吗？
不是。进程退出可能发生在请求到达 API 之前。如果日志里出现 HTTP 500、request id 或服务端错误，请转到 Claude Code API Error 500 指南。如果证据指向额度、用量窗口或明确限制，请看 Claude Code rate limit 指南。
工作规则
把 Claude Code 退出代码 1 当成分支路由问题：先识别启动入口，选择破坏性最小的归属检查，一次只改一个变量，回到同一路径验证；只有同一路径仍失败并且证据清楚时，才升级到 issue 或支持。