another Claude Code process is refreshing it：续期锁被占怎么办

看到 Failed to refresh OAuth token: another Claude Code process is refreshing it or exited mid-refresh，说明你的登录并没有被拒绝。保存的 claude.ai 登录到期、需要续期，而同一台机器上另一个 Claude Code 进程正占着续期用的锁，或者续期到一半就退出、把锁留在了原处，所以 Claude Code 在请求发出之前就停了下来。这把锁是配置目录里一个名为 .oauth_refresh.lock 的空目录，默认路径是 ~/.claude/.oauth_refresh.lock（Claude Code 官方错误参考里的这一条只讲到"共享的续期锁"，目录名来自下文的实测）。

现在先等一分钟再试。在 macOS 和 Linux 上，一把超过 60 秒没人更新的锁会在下一次运行时被自动收回：2026 年 11 月 12 日在一台 Mac 上用 Claude Code 2.1.316 复现，锁刚出现时立刻重跑仍然报同一句，65 秒后再跑就正常续期了。如果反复出现，就关掉其他 Claude Code 窗口和进程；确认已经没有 Claude Code 进程在跑、锁也不再变化后，用 rmdir ~/.claude/.oauth_refresh.lock 删掉这个空目录；仍然不行再执行 /login。不要为这句报错删除 .credentials.json 或钥匙串里的登录。

有两种情况等多久都不会好：Windows 上有用户报告锁目录等了 180 秒仍在；系统时间往回跳过时，锁的修改时间落在"未来"，永远不会被判定为过期。这两种都要按下文的只读检查确认后手动删除。如果你看到的是 OAuth session expired and could not be refreshed，那是另一句报错，处理方法见Claude unable to authenticate 无法认证：先查事故，再修本机或账号。

报错原文的两种写法：登录没被拒，是续期锁被占

这句报错有交互模式和非交互模式两种写法，Anthropic 在官方错误参考里把它们归在同一条下，并说明这不代表登录被拒：保存的登录已经到期，另一个进程持有共享的续期锁或退出时把锁留下，当前会话等待期间续期没有任何进展。在终端里直接用 Claude Code 时，你看到的是：

Could not refresh your login because another Claude Code process is refreshing it (or exited mid-refresh) · Try again in a minute; if it keeps happening, close other Claude Code windows or sign in again with /login

用 claude -p 跑脚本或通过 Agent SDK 调用时，看到的是下面这句，结构化错误码是 server_error：

Failed to refresh OAuth token: another Claude Code process is refreshing it or exited mid-refresh. This is usually transient; retry in a minute, and if it persists close other Claude Code processes or sign in again

这两句不是转述。2026 年 11 月 12 日对一台 Mac（Apple 芯片）上 Claude Code 2.1.312、2.1.314、2.1.316 三个版本的程序文件做字节搜索，两种写法都原样在里面，三个版本完全相同；同一处还有磁盘已满的那句和 Failed to authenticate: OAuth session expired and could not be refreshed，说明它们是程序里分开的几种情况。

常说的"锁文件"其实不止一个文件。2026 年 11 月 12 日在一台 Mac 上用 Claude Code 2.1.316 观察一次正常续期，锁由下面三样东西组成，进程退出后三样都消失。测试用的是隔离配置目录（CLAUDE_CONFIG_DIR）里的假凭据，没有动用真实登录。下文按表里的名字称呼它们。

如果设置了 CLAUDE_CONFIG_DIR，这三样都跟着配置目录走：续期锁目录和持有者记录在那个目录里，旧式锁目录是"那个目录的路径加 .lock"。下文命令都按默认的 ~/.claude 写，用了自定义目录时自行替换。

另外两句长得很像的报错处理方法不同。报错开头是 Error during compaction: 时，问题出在压缩对话这一步，见Claude Code 压缩失败：Error compacting conversation 原因与恢复；报错写的是 the disk that holds the Claude Code config directory (~/.claude by default), or your disk quota on it, is full，则是配置目录所在的磁盘满了，官方的说法是腾出空间后重发，重新登录没有用，因为新的登录也存不下。

为什么是"一分钟后重试"：60 秒过期规则和实测时间

"一分钟"对应的是续期锁的过期时间。从 Claude Code 2.1.316 的程序里能读到这套规则：正在续期的进程每 5 秒更新一次续期锁目录的修改时间；修改时间超过 60 秒没变的锁被视为过期，下一个进程会把它删掉自己接手；等待的进程遇到锁被占，会以 1 到 2 秒的随机间隔重试 5 次，再用 7.5 秒观察锁的修改时间有没有变化，没变就放弃并报出这句话。也就是说，看到这句话时，锁在你等待的那几秒里没有动过，持有它的进程要么卡住了，要么已经不在了。

2026 年 11 月 12 日在一台 Mac 上用 2.1.316 的 claude -p 实际跑了几种情况，条件同上一节（隔离配置目录、假凭据），结果和规则对得上。一个刚创建、之后没人碰的续期锁目录，让命令在约 8 秒后报出 -p 那句（三次分别为 7.9、8.0、8.6 秒），退出码 1，立刻重跑结果相同；同一把锁在创建 65 秒后再跑就被自动收回，正常进入续期；修改时间在 5 分钟前的锁则当场被收回。只放一个旧式锁目录、不放续期锁目录，同样约 7.9 秒报出这句。反过来，用辅助脚本每 2 秒更新一次锁的修改时间、模拟持有者还活着时，这句话没有出现，Claude Code 等了约 35 秒后改用旧凭据发出请求。最麻烦的是修改时间在 30 天之后的锁：它当场报这句，65 秒后再跑照样报，rmdir 删掉续期锁目录后才马上恢复。

没有测过的有四项：Windows、两个真实登录同时续期、持有者已死但留有持有者记录的情况，以及旧式锁目录过了 60 秒会不会自动收回。程序里还有一条"接管已死持有者"的路径：持有者记录能证明那个进程号在本机已经不存在、且服务器端的开关允许时，Claude Code 会提前接手这把锁。官方更新日志里 2.1.282 也写了修复"另一个进程被关闭或杀掉后，请求最多一分钟内失败"的问题。这个开关在你的账号上是否打开无从得知，所以 2.1.282 之后，持有者真的崩掉时你可能会更快恢复，但不能保证。

你是哪种情况：按当时在做什么对照

先回想报错前几分钟发生了什么，这比报错本身更能说明原因。下表除最后一列的处理方法外，原因均来自 Claude Code 的 GitHub issue 里的用户报告；标了"实测"的是 2026 年 11 月 12 日在 Mac 上复现过的。

涉及 Claude in Chrome 的设置和其他报错，见Claude Code 操作浏览器：Claude in Chrome 怎么用、权限与报错排查。

不动任何文件，先查清谁占着续期锁

下面三步只读不写，目的是回答两个问题：还有没有 Claude Code 进程活着，以及续期锁是不是还在被更新。顺序要按这个来，因为第三步需要用到前两步的结果。

1. 看还有没有别的 Claude Code 进程（依据：官方错误参考要求先关掉其他 Claude Code 窗口和进程）。macOS 和 Linux 上运行下面的命令。列表里也会出现 Claude 桌面 App 的进程；要找的是命令为 claude、claude -p …、claude auth status、claude --chrome-native-host 的行，以及 VS Code 扩展自带的 Claude Code。Windows 上用 PowerShell 运行 Get-Process claude。

   bash复制

   ps ax -o pid,lstart,command | grep -i '[c]laude'

2. 看锁在不在、多久没动（依据：2.1.316 程序里每 5 秒更新、60 秒过期的规则）。先列出两个锁目录，再看续期锁目录的修改时间并和当前时间对比，隔 10 秒再看一次。

   bash复制

   ls -ld ~/.claude/.oauth_refresh.lock ~/.claude.lock
   date; stat -f '%Sm' -t '%Y-%m-%d %H:%M:%S' ~/.claude/.oauth_refresh.lock   # macOS
   date; stat -c '%y' ~/.claude/.oauth_refresh.lock                           # Linux

   10 秒内修改时间变了，说明有进程正在续期，等它完成即可；没变且已经早于现在 60 秒以上，下一次运行应当自动收回（macOS 和 Linux）；修改时间晚于现在，就是上一节表格里"时间落在未来"的情况，不会自己消失。两个目录都不存在时，锁已经释放，直接重发。

3. 读持有者记录，确认那个进程还在不在（依据：2026 年 11 月 12 日在 Mac 上用 2.1.316 抓到的文件内容）。记录里的 pid 是持有者的进程号，procStart 是它的启动时间，pidSpace 是主机名。

   bash复制

   cat ~/.claude/.oauth_refresh.lock.owner
   # 例：{"pid":86099,"procStart":"Wed Nov 11 23:43:47 2026","pidDomain":"darwin","pidSpace":"你的主机名","lockBirthtimeMs":1794440627689.523,"legacyLockBirthtimeMs":1794440627689.7253}
   ps -p 86099 -o pid,lstart,command

   ps 没有输出，或者列出的启动时间和 procStart 对不上（进程号被别的程序重用了），说明持有者已经不在。进程还在、启动时间也对得上，这个进程就是占着锁的那个。没有持有者记录时，只看前两步的结果。

逐级清锁：等一分钟、关进程、删空目录、再 /login

处理顺序从风险最小的开始，每一步做完就重发一次请求，好了就停下。前两步来自官方错误参考，第三步来自 GitHub issue 里的用户报告并在 Mac 上复现过，第四步来自官方错误参考。

1. 等一分钟再发。 另一个进程先完成续期时，当前会话会直接用续期后的登录；没人更新的锁在 macOS 和 Linux 上过 60 秒会被收回。只有旧式锁目录卡住时，报告者也是等约一分钟后重发就好了。
2. 关掉占着锁的那个进程。 正常退出另一个 Claude Code 会话或关闭多余的 VS Code 窗口；如果上一节查到的持有者是一个卡住的短命令或后台进程，用 kill <进程号> 只结束它。在续期中途结束进程本身就可能把空的续期锁目录留下（#105729 里一位用户 2026 年 10 月 31 日用假凭据复现：锁一出现就结束进程，8 次都留下了），所以结束后再等一分钟，仍报就进入第 3 步。
3. 确认没有 Claude Code 进程、锁也不再变化后，删掉空的续期锁目录。 macOS 和 Linux 用 rmdir ~/.claude/.oauth_refresh.lock，Windows 用 Remove-Item "$HOME\.claude\.oauth_refresh.lock"。两位用户在 #95236 报告删除后下一次 claude -p 立即成功，#95739 里时间落在未来的锁也是这样解决的；2026 年 11 月 12 日在 Mac 上复现时，rmdir 后同样马上恢复。rmdir 只能删空目录，目录里有东西时它会报错，这正好防止误删。
4. 仍然报，执行 /login。 官方的说明是重新登录不等待续期锁；非交互环境里，#95236 和 #79688 的报告者用的是 claude auth login。

要不要删 .credentials.json、钥匙串或重装：不需要

删除登录凭据只会让情况更糟。官方已经说明这句报错不是登录被拒，保存的登录本身没有问题，卡住的只是续期这一步；Windows、Linux 和容器里的 .credentials.json，或 macOS 钥匙串里名为 Claude Code-credentials 的条目，一旦删掉，你就真的掉了登录，还得重新授权。重装 Claude Code 也碰不到续期锁目录，因为它在配置目录里而不在安装目录里。另一个常见建议是用 pkill -f claude 一次结束所有进程，但它会匹配命令行里含 claude 的任何程序，包括 Claude 桌面 App，而且在续期中途强行结束进程正是留下空锁目录的原因之一；只结束上一节查到的那一个进程就够了。

Windows 上锁目录不会自己消失：用户报告与处理

Windows 上的表现和 macOS 实测不同。#95236 的报告者在 Windows 11、Claude Code 2.1.272 上批量跑 claude -p，空的续期锁目录等了 180 秒依然导致失败，尽管程序里的过期时间同样是 60 秒；删除 %USERPROFILE%\.claude\.oauth_refresh.lock 后立即恢复，同一 issue 里还有人在 Linux 的 Docker 沙箱里遇到同样情况。原因至今不明，报告者升级后没再遇到，但他自己也说这说明不了什么。所以在 Windows 上，锁目录存在超过一两分钟、又确认没有 Claude Code 进程时，不必继续等，直接按上一节第 3 步用 Remove-Item 删除。另外两类报告也只出现在 Windows：多个进程同时启动时创建锁目录报 EPERM: operation not permitted, mkdir，随后每天早上都要重新登录（#91708）；~/.claude 里堆积大量 .oauth_refresh.lock.owner.tmp.* 文件，报告者暂未发现影响使用（#108764）。截至 2026 年 11 月 12 日，这两件事在更新日志里都没有修复记录。

哪些版本修过这把锁：2.1.248 到 2.1.318 的更新记录

Anthropic 在官方更新日志里多次修改过续期锁的行为，截至 2026 年 11 月 12 日（日志最新为 2.1.322），和这句报错直接相关的有下面这些。发布日期取自 GitHub Releases。

更早的 2.1.211 也改过一处：官方故障排查页说，在这个版本之前，电脑从睡眠中唤醒可能让两个会话用同一个令牌同时续期，导致保存的登录被吊销、所有会话一起要求重新登录。

2.1.301 修的是一类问题，即短命令在续期中途退出，claude auth status 和 claude plugin list 只是日志里举的例子；此后用户又复现了短命令在较慢的续期保存之前退出：#102265 是 claude plugin validate（2.1.302、2.1.303），#105645 是 claude auth status（2.1.311），随后才有 2.1.317 和 2.1.318 两条。所以由短命令引起的这句报错，第一步是升级到 2.1.318 或更新。claude doctor、claude agents --json、claude --bg 在日志里没有被点名。#103325 的报告者在 Windows 上用 2.1.296 到 2.1.303，调度器定时跑 claude auth status 和 claude agents --json，多个进程共用一份登录，十天里两次掉了登录；那是两个进程同时续期的竞争，不是这句报错本身。截至 2026 年 11 月 12 日，GitHub 上没有 2.1.318 之后短命令丢失续期的报告。调用方在续期中途结束进程的情况，2.1.282 那条"另一个进程在续期中途被关闭或杀掉"已经覆盖；#105729 里网关探测命令超时被杀、8 次都留下空锁目录的复现，来自 2026 年 10 月 31 日的一条评论，没有写明版本（这个 issue 本身是在 2.1.280 上提交的）。时间落在未来的锁、Windows 上的 EPERM、--chrome-native-host、VS Code 配置缓存进程留下的旧式锁目录、.owner.tmp 残留文件，同样没有修复记录。2.1.316 里这句报错和整套锁逻辑依然存在，用户在 2.1.295 和 2.1.301 上也报告过看到它。Anthropic 员工在相关 issue 里只回复过一次：2026 年 8 月 16 日，bcherny 在 #79688 里说"看起来是真实的 bug"，并询问失败后是否留有锁文件，但这个 issue 后来被机器人以长期无活动为由关闭。把它当作一个还没完全解决的已知问题来对待比较稳妥。

多窗口、脚本、服务器和容器里怎样避免再出现

续期锁只在多个进程共用一份保存的登录、又恰好同时续期时才会出问题，所以预防的思路是让续期只由一个进程在安静的时候完成。下面按环境分开写，标了"用户报告"的是 GitHub issue 里报告者自己用的办法。

• 在 VS Code 里每天早上第一次打开就报，多半是几个窗口同时恢复、同时续期。用户报告的两个办法是把 VS Code 设置 "window.restoreWindows" 改成 "one"（#90688），或者在打开 VS Code 之前先在终端跑一次 claude -p，让登录提前续好（#102785、#79688）。想确认 VS Code 里用的是哪个账号，见Claude Code 在 VS Code 里怎么查看账号：先跑 /status，再判断登录和 API 路由；扩展本身打不开时见Claude Code 在 VS Code 里用不了？先定位失败表面。
• 用 claude -p 跑批处理或通过 Agent SDK 调用时，官方建议无法交互登录的自动化改用 ANTHROPIC_API_KEY，或用 claude setup-token 生成长期令牌；这两种方式不走保存登录的续期流程（官方文档与 2.1.316 的程序）；据此推断它们不会碰到这把续期锁，官方文档里没有这句话。继续用订阅登录时，用户报告的做法是闲置一段时间后先单独跑一次 claude -p，等它正常返回再放开其余任务（#88583），重试间隔不要短于 60 秒。
• 监控脚本、SSH 登录横幅或网关定时调用 claude auth status、claude doctor、claude agents --json 时，这类短命令会在启动时触发续期，先把 Claude Code 升级到 2.1.318 或更新。有用户复现过这类命令在续期中途被超时杀掉后留下空的续期锁目录（#105729，2026 年 10 月 31 日的评论，未写版本），所以不要给这些命令设过短的超时；用户报告的另一个办法是改用 claude -p /usage 触发续期（#95822）。后台会话 claude --bg 也在报告的短命令之列，它的用法见Claude Code Agent View 怎么用：启动、切换和找回后台会话。
• 在一台服务器上同时开很多个会话时，用户报告的做法是只跑一个 claude remote-control 服务进程，用 --capacity N 承载多个会话，代替同时启动许多个独立进程（#91708）。
• 在容器或虚拟机里，先确认系统时间准确。官方故障排查页提醒，频繁要求登录时要检查系统时钟；开机后时间往回校正，可能留下时间落在未来、永远不会过期的锁（#95739）。