Failed to refresh OAuth token: another Claude Code process 오류 해결

Claude Code가 Failed to refresh OAuth token: another Claude Code process is refreshing it or exited mid-refresh라는 문장으로 멈췄다면, 번역하면 "다른 Claude Code 프로세스가 OAuth 토큰을 갱신하고 있거나 갱신 도중 종료되어, 토큰을 갱신하지 못했다"는 뜻입니다. 로그인이 거부된 것이 아닙니다. 저장된 로그인이 만료되어 갱신이 필요했는데, 같은 컴퓨터의 갱신 잠금인 ~/.claude/.oauth_refresh.lock(빈 폴더)을 다른 프로세스가 쥐고 있었거나 갱신 도중 꺼지면서 남겨 두었고, 그래서 Claude Code가 요청을 보내기 전에 멈춘 것입니다(Claude Code 공식 오류 문서의 이 메시지 항목).

그러니 먼저 1분 기다렸다가 같은 명령을 다시 실행합니다. 아무도 손대지 않는 잠금은 마지막 갱신 후 60초가 지나면 다음 실행이 스스로 치우기 때문이고, 2026년 11월 12일 Claude Code 2.1.316으로 재현했을 때도 만든 지 65초 된 잠금은 저절로 풀렸습니다. 그래도 반복되면 다른 Claude Code 창과 프로세스를 닫습니다. Claude Code가 하나도 떠 있지 않은데 잠금 폴더가 남아 있다면 그 빈 폴더만 rmdir로 지우고, 그래도 안 되면 /login으로 다시 로그인합니다. .credentials.json이나 macOS 키체인 항목은 지우지 않습니다.

1분으로 해결되지 않는 경우가 세 가지 있습니다. 시스템 시계가 뒤로 돌아가 잠금 폴더의 수정 시각이 미래로 찍혔다면 잠금이 저절로 풀리지 않고, Windows에서는 3분을 기다려도 풀리지 않았다는 보고가 있으며, 짧은 명령이 갱신 도중 끝나면서 남긴 잠금이 손으로 지울 때까지 그대로였다는 Linux 컨테이너 보고도 있습니다. 이 보고는 2.1.283에서 나왔고, 짧은 명령이 갱신 도중 끝나는 문제는 2.1.301에서 고쳐졌다고 변경 기록에 적혀 있습니다. 어느 쪽인지는 아래의 읽기 전용 확인으로 가릴 수 있습니다.

오류 뜻: 로그인 거부가 아니라 OAuth 갱신 잠금에 막힌 것

이 오류는 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에서는 아래 문장이 나오고, SDK가 돌려주는 구조화된 오류 코드는 server_error입니다(공식 오류 문서). 2026년 11월 12일 재현에서 claude -p의 종료 코드는 1이었습니다.

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

뒷부분은 "보통 일시적이니 1분 뒤 다시 시도하고, 계속되면 다른 Claude Code 프로세스를 닫거나 다시 로그인하라"는 뜻입니다. 공식 문제 해결 문서는 같은 컴퓨터의 여러 세션이 저장된 로그인 하나를 함께 쓰고, 한 번에 한 프로세스만 토큰을 갱신하도록 순서를 맞춘다고 설명합니다(Claude Code 설치·로그인 문제 해결 문서). 그 순서를 정하는 장치가 갱신 잠금이고, 이 오류는 순서를 기다리다 포기했다는 신호입니다.

흔히 "잠금 파일"이라고 부르지만 실제로는 폴더와 파일이 섞인 세 가지입니다. 2026년 11월 12일 Claude Code 2.1.316이 토큰을 갱신하는 순간 설정 폴더를 들여다보면 다음이 생겨 있었고, 정상 종료 후에는 셋 다 사라졌습니다.

~/.claude/.oauth_refresh.lock        # 갱신 잠금 폴더(비어 있는 디렉터리)
~/.claude/.oauth_refresh.lock.owner  # owner 파일(누가 잠금을 쥐었는지 적힌 JSON)
~/.claude.lock                       # 예전 잠금 폴더(~/.claude 옆에 생기는 디렉터리)

owner 파일에는 잠금을 쥔 프로세스의 pid, 그 프로세스의 시작 시각(procStart, ps의 lstart 형식), 운영체제(pidDomain, Mac에서는 "darwin"), 컴퓨터 이름(pidSpace), 잠금을 만든 시각(lockBirthtimeMs, legacyLockBirthtimeMs)이 들어 있습니다. CLAUDE_CONFIG_DIR로 설정 폴더를 바꿨다면 갱신 잠금 폴더와 owner 파일은 그 폴더 안에, 예전 잠금 폴더는 <그 폴더 경로>.lock으로 옮겨 갑니다. 아래에서는 이 세 가지를 위의 이름으로 부릅니다.

"1분 뒤 재시도"의 근거: 60초 동안 안 움직인 잠금은 풀린다

1분이라는 숫자에는 이유가 있습니다. Claude Code 2.1.316 실행 파일에 들어 있는 잠금 설정을 보면, 잠금을 쥔 프로세스는 5초마다 갱신 잠금 폴더의 수정 시각을 새로 찍고(update: 5000), 수정 시각이 60초 넘게 멈춘 잠금은 버려진 것으로 보고 지웁니다(stale: 60000). 기다리는 쪽은 1~2초 간격으로 5번 다시 잡아 본 뒤, 7.5초 사이에 잠금이 움직였는지 확인합니다. 움직이지 않았으면 쥔 쪽이 멈췄다고 판단하고 이 오류를 냅니다. 그래서 갱신하던 프로세스가 죽었다면, 마지막 표시로부터 60초 뒤의 실행은 잠금을 치우고 정상적으로 갱신합니다.

실제로 어떻게 움직이는지는 2026년 11월 12일 Mac 한 대에서 Claude Code 2.1.316으로 확인했습니다. 실제 로그인은 쓰지 않고, CLAUDE_CONFIG_DIR로 만든 격리된 설정 폴더에 가짜 자격 증명을 넣은 뒤 잠금 상태를 바꿔 가며 claude -p를 실행했습니다. 방금 만든 빈 갱신 잠금 폴더를 아무도 건드리지 않게 두면 약 8초(7.9·8.0·8.6초) 뒤 위의 -p 문장이 나왔고, 바로 다시 실행해도 같았습니다. 같은 잠금을 만든 지 65초 뒤에 실행하자 잠금이 자동으로 치워졌고, 수정 시각이 5분 전인 잠금은 처음부터 바로 치워졌습니다. 실패한 재시도가 잠금 시간을 늘리지 않으므로 바로 연달아 실행할 필요는 없고, 1분 기다리는 쪽이 빠릅니다.

예외도 같은 실행에서 드러났습니다. 수정 시각이 30일 뒤로 찍힌 잠금은 65초 뒤에도 같은 문장을 냈고, 그 폴더를 rmdir로 지우자 곧바로 정상 경로(3.0초)로 돌아갔습니다. 예전 잠금 폴더 <설정 폴더>.lock만 있어도 같은 문장이 약 7.9초 만에 나왔습니다. 반대로 2초마다 수정 시각을 바꿔 "살아 있는 보유자"를 흉내 낸 잠금에서는 이 문장이 나오지 않았고, 35초 기다린 뒤 기존 토큰으로 요청을 보냈습니다. 즉 이 문장을 봤다면, 적어도 그 몇 초 동안은 잠금을 쥔 쪽이 움직이지 않았다는 뜻입니다.

이 재현으로 확인하지 않은 것도 있습니다. Windows, 실제 로그인 두 개가 동시에 갱신을 다투는 상황, owner 파일이 남은 채 보유자가 죽은 경우, 예전 잠금 폴더가 60초 뒤 저절로 풀리는지는 실행하지 않았습니다. 2.1.282 변경 기록에는 "다른 프로세스가 갱신 도중 닫히거나 종료된 뒤 최대 1분 동안 요청이 실패하던 문제"를 고쳤다고 적혀 있고, 2.1.316 코드에는 owner 파일로 보유자가 이 컴퓨터에서 이미 죽었음이 증명되면 60초를 기다리지 않고 잠금을 넘겨받는 경로가 있습니다. 다만 이 경로는 Anthropic이 원격으로 켜고 끄는 설정에 묶여 있어, 계정에 따라 1분보다 더 빨리 풀릴 수도 있다는 정도만 말할 수 있습니다.

내 경우는 어느 쪽인가: 직전 상황별 원인과 첫 조치

원인은 오류가 뜨기 직전에 무엇을 하고 있었는지로 대부분 가려집니다. 아래 표는 GitHub에 올라온 사용자 보고와 2026년 11월 12일 재현 결과를 직전 상황별로 묶은 것입니다. 표에 적힌 원인은 Anthropic이 확인한 것이 아니라 보고자들이 관찰한 내용입니다.

Claude in Chrome 연결 자체가 처음부터 안 된다면 이 표가 아니라 Claude in Chrome 설치와 사용법: Claude Code 연결, API 키로 안 되는 이유를 봅니다.

아무것도 바꾸지 않고 잠금을 쥔 프로세스 확인하기

무엇을 지우기 전에, 지금 잠금이 있는지, 누가 쥐었는지, 그 프로세스가 살아 있는지를 먼저 봅니다. 아래 명령은 모두 읽기만 하므로 언제 실행해도 상태가 바뀌지 않습니다. 확인할 항목은 2026년 11월 12일 재현에서 본 잠금 구성과 2.1.316 코드의 규칙(5초마다 갱신, 60초 지나면 오래된 잠금)에서 나왔습니다. macOS·Linux 기준이며 CLAUDE_CONFIG_DIR을 쓴다면 ~/.claude를 그 경로로 바꿉니다.

1. 떠 있는 Claude Code 프로세스를 봅니다. 터미널 세션, VS Code 확장이 띄운 프로세스, --chrome-native-host, 백그라운드 세션이 모두 여기에 나옵니다.

   bash복사

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

2. 잠금 폴더가 남아 있는지 봅니다. 둘 다 "No such file or directory"라면 잠금은 이미 풀렸으니 바로 다시 실행하면 됩니다.

   bash복사

   ls -ld ~/.claude/.oauth_refresh.lock ~/.claude.lock

3. owner 파일이 있으면 잠금을 쥔 pid를 읽고, 그 프로세스가 아직 있는지 봅니다. ps가 아무것도 보여 주지 않거나, 보여 준 시작 시각이 owner 파일의 procStart와 다르면 원래 보유자는 이미 사라진 것입니다.

   bash복사

   cat ~/.claude/.oauth_refresh.lock.owner
   ps -p <pid> -o pid,lstart,command

4. 잠금의 수정 시각을 10초쯤 간격을 두고 두 번 보고, 현재 시각과 비교합니다. Mac은 첫 줄, Linux는 둘째 줄을 씁니다.

   bash복사

   stat -f '%Sm' ~/.claude/.oauth_refresh.lock; date
   stat -c '%y' ~/.claude/.oauth_refresh.lock; date

Windows PowerShell에서는 같은 내용을 이렇게 봅니다. 프로세스 이름은 claude.exe이고 폴더 위치는 %USERPROFILE%\.claude입니다.

Get-Process claude -ErrorAction SilentlyContinue
Get-Item -Force "$HOME\.claude\.oauth_refresh.lock" | Select-Object LastWriteTime
Get-Content "$HOME\.claude\.oauth_refresh.lock.owner"

결과는 이렇게 읽습니다. 수정 시각이 두 번 볼 때마다 바뀐다면 누군가 지금 갱신 중이니 기다리거나 그 프로세스를 닫을 차례입니다. 수정 시각이 멈춰 있고 60초가 안 됐다면 60초가 지날 때까지 기다리면 됩니다. 60초가 훨씬 지났거나 현재 시각보다 미래인데 잠금 폴더가 그대로이고, 1번에서 Claude Code 프로세스가 하나도 없다면 다음 절의 3단계(빈 폴더 삭제)에 해당합니다. 갱신 잠금 폴더 없이 ~/.claude.lock만 있으면 예전 잠금 폴더 경우입니다.

푸는 순서: 1분 대기 → 프로세스 종료 → 잠금 삭제 → /login

조치는 덜 위험한 것부터 하나씩 하고, 각 단계에서 해결되면 거기서 멈춥니다. 1·2·4단계는 공식 오류 문서의 순서이고, 3단계는 GitHub 사용자 보고와 2026년 11월 12일 재현에서 나온 것입니다.

1. 1분 기다렸다가 같은 명령을 다시 실행합니다. 다른 프로세스가 갱신을 먼저 끝냈다면 이 세션은 새로 갱신된 로그인을 그대로 씁니다(공식 문서). 잠금을 쥔 쪽이 죽었다면 60초 뒤 실행이 잠금을 치웁니다.

2. 다른 Claude Code 창과 프로세스를 닫고 다시 시도합니다. 앞 절 1번에서 본 프로세스 중 필요 없는 것을 그 창에서 정상 종료하고, 응답이 없는 것만 kill <pid>로 하나씩 끝냅니다. pkill -f claude처럼 이름으로 한꺼번에 끄면 명령줄에 claude가 들어간 다른 앱(예: Claude 데스크톱 앱)까지 잡힐 수 있으므로 쓰지 않습니다.

3. Claude Code가 하나도 없고 잠금이 움직이지 않을 때만, 빈 갱신 잠금 폴더를 지웁니다. rmdir은 비어 있는 폴더만 지우고 내용물이 있으면 실패하므로, 실패하면 거기서 멈추고 무엇이 들어 있는지 먼저 봅니다. Windows와 Linux Docker 환경에서 이 폴더를 지우자 다음 claude -p가 바로 성공했다는 보고(#95236), 시계가 되돌아간 컨테이너에서 같은 자격 증명으로 즉시 갱신됐다는 보고(#95739)가 있고, 2026년 11월 12일 재현에서도 미래 시각 잠금을 지우자 곧바로 정상 경로로 돌아갔습니다. Windows 명령은 #95236 보고자가 쓴 것입니다.

   bash복사

   rmdir ~/.claude/.oauth_refresh.lock

   powershell복사

   Remove-Item "$HOME\.claude\.oauth_refresh.lock"

4. 그래도 반복되면 /login으로 다시 로그인합니다. 공식 문서에 따르면 새로 로그인하는 과정은 갱신 잠금을 기다리지 않습니다. claude -p 스크립트에서 난 오류라면 같은 환경에서 claude를 실행해 /login을 마친 뒤 스크립트를 다시 돌립니다.

예전 잠금 폴더 ~/.claude.lock만 남은 경우는 보고자가 약 1분 뒤 다시 보내서 해결했습니다(#102785). 이 폴더를 손으로 지우는 절차는 공식 문서에도 이슈에도 없으므로, 1분 뒤에도 남아 있으면 2단계와 4단계로 넘어갑니다.

어느 버전에서 고쳐졌나: Claude Code 2.1.248~2.1.318 변경 기록

갱신 도중 죽은 프로세스 때문에 최대 1분 실패하던 문제는 2.1.282에서, 짧은 명령이 갱신 도중 끝나던 문제는 2.1.301에서 고쳐졌고, 그 뒤에도 느린 갱신을 저장하기 전에 끝나던 claude auth status와 claude plugin 명령은 2.1.317·2.1.318에서 마저 고쳐졌습니다. 2026년 11월 12일 기준 Claude Code 변경 기록(CHANGELOG)의 최신 버전은 2.1.322이고, 이 잠금과 직접 관련된 항목은 아래와 같습니다. 배포일은 GitHub 릴리스 기준이며, 내 버전은 claude --version으로 확인합니다.

반대로 변경 기록 어디에도 없는 것도 있습니다. 2.1.322까지 Windows의 EPERM 잠금 실패, 시계가 되돌아가 미래 시각으로 찍힌 잠금, --chrome-native-host, VS Code의 설정 캐시 프로세스, 예전 잠금 폴더 ~/.claude.lock, Windows에 쌓이는 .oauth_refresh.lock.owner.tmp.* 파일에 대한 수정 항목은 없습니다. 이 오류를 다룬 GitHub 이슈들에서 Anthropic 직원이 단 답글도 2026년 8월 16일 #79688의 "실제 버그로 보인다, 버그로 열어 두겠다"는 한 건뿐인데, 이 이슈는 2026년 9월 19일 자동 정리 봇이 닫았습니다. 어느 이슈에도 "몇 버전에서 고쳤다"는 직원 답변은 없으므로, 위 표 이후 버전에서 "아직 그대로"라는 말은 모두 사용자 보고로 봐야 합니다.

매일 아침, VS Code 여러 창, 스크립트·서버에서 반복될 때

반복되는 환경에는 공통점이 있습니다. 저장된 로그인이 만료된 직후, 여러 프로세스가 한꺼번에 갱신하려 하거나 갱신을 시작한 프로세스가 금방 끝나 버립니다. 그래서 첫 갱신을 프로세스 하나에게 먼저 맡기고, 갱신 도중 프로세스를 끊지 않는 것이 재발 방지의 핵심입니다. 아래는 환경별로 보고된 방법이며, 공식 문서에서 온 것은 따로 표시했습니다.

• VS Code가 창 여러 개를 복원하며 시작할 때는 VS Code 설정에 "window.restoreWindows": "one"을 넣어 창을 하나만 복원하게 한 사용자가 있고(#90688), VS Code를 열기 전에 터미널에서 claude -p 한 번으로 먼저 갱신해 두는 방법도 여러 이슈에 올라와 있습니다(#79688, #102785). VS Code가 어느 로그인을 쓰는지는 VS Code에서 Claude Code 계정 확인하기: /status, 로그인, API 경로에서, 확장 자체가 안 뜨는 문제는 Claude Code가 VS Code에서 안 될 때는 먼저 실패 지점을 나눠야 한다에서 나눠 봅니다.
• claude -p를 여러 개 동시에 돌리는 스크립트라면, 쉬었다가 다시 시작할 때 하나를 먼저 실행해 실제 응답을 받은 뒤 나머지를 띄우라는 보고가 있습니다(#88583). 스크립트의 재시도는 종료 코드 1이나 SDK의 server_error를 받으면 최소 60초 뒤에 하도록 두는 편이 잠금 규칙과 맞습니다.
• 모니터링, SSH 로그인 배너, 게이트웨이 상태 점검처럼 짧은 명령을 주기적으로 돌린다면 먼저 최신 버전으로 올립니다. 짧은 명령이 갱신 도중 끝나는 문제는 2.1.301에서 고쳐졌고, 그 뒤 사용자들이 2.1.302·2.1.303(claude plugin validate)과 2.1.311(claude auth status)에서 느린 갱신을 저장하기 전에 끝나는 경우를 다시 재현하자 2.1.317·2.1.318이 auth status와 plugin 명령의 이 경우를 고쳤습니다. claude doctor, claude agents --json, claude --bg 런처는 어느 변경 기록 줄에도 이름이 나오지 않습니다. Windows 2.1.296~2.1.303에서 스케줄러가 claude auth status와 claude agents --json을 돌리다 로그인이 두 번 풀렸다는 보고(#103325)가 있지만, 이 오류 문장이 아니라 토큰 교체 경합 사례입니다. 2026년 11월 12일 기준 2.1.318 이후 버전에서 짧은 명령 문제를 다시 보고한 공개 이슈는 없습니다. 호출한 쪽이 타임아웃으로 프로세스를 끊는 경우는 2.1.282의 "갱신 도중 닫히거나 종료된(killed) 프로세스" 수정에 해당합니다. 게이트웨이가 상태 점검용 claude auth status --json을 SIGTERM이나 SIGKILL로 끊자 빈 잠금 폴더가 8번 중 8번 남았다는 보고(#105729)는 2026년 10월 31일 댓글로, 어느 버전인지는 적혀 있지 않습니다(이슈 자체는 2.1.282 이전인 2.1.280에서 등록됐습니다). 그래도 갱신 도중 Claude Code를 끊으면 잠금이 남을 수 있으므로 타임아웃은 갱신이 끝날 만큼 여유 있게 잡습니다. 업데이트 후에도 반복된다면 보고자들이 쓴 우회를 선택적으로 시도해 볼 수 있습니다. 상태 확인을 claude doctor나 claude auth status 대신 claude -p /usage로 해서 갱신이 끝까지 저장되게 하는 방법입니다(#95822). 백그라운드 세션 사용법은 Claude Code Agent View 사용법: 백그라운드 세션 시작부터 답장·복구까지에 있습니다.
• 사람이 로그인할 수 없는 서버·자동화에는 공식 문서가 ANTHROPIC_API_KEY나 claude setup-token으로 만든 장기 토큰을 쓰라고 안내합니다(공식 오류 문서의 Login expired 항목). 이 두 방식은 저장된 로그인의 갱신을 쓰지 않으므로 이 잠금과 엮이지 않는다고 보는 것이 자연스럽지만, 문서에 그렇게 적혀 있지는 않고 문서와 2.1.316 코드에서 추론한 것입니다. 여러 세션을 한 서버에서 돌려야 한다면 프로세스 여러 개 대신 claude remote-control 서버 하나를 --capacity N으로 띄웠다는 사용자도 있습니다(#91708).
• 컨테이너나 VM에서는 부팅 직후 시간 동기화로 시계가 몇 시간 뒤로 돌아가면 잠금이 미래 시각으로 남습니다(#95739). 공식 문제 해결 문서도 로그인 요청이 잦으면 시스템 시계를 확인하라고 권하므로, 부팅 후 시계가 맞춰진 다음에 Claude Code를 시작하게 순서를 잡습니다.

Windows에서는 60초가 지나도 안 풀린다는 보고

Windows에서는 macOS 재현과 다른 결과가 보고됐습니다. 2.1.272를 쓰던 Windows 11 사용자는 claude -p 일괄 작업 중 빈 갱신 잠금 폴더가 남았고, 180초를 기다려 다시 실행해도 같은 오류가 났지만 폴더를 지우자 바로 해결됐다고 했습니다(#95236). 60초 규칙이 같은 설정으로 들어 있는데도 Windows에서 동작하지 않은 이유는 공개된 설명이 없습니다. 같은 보고자는 업데이트 후 다시 겪지 않았지만 원래도 마음대로 재현되지 않았으니 의미 있는 결과는 아니라고 덧붙였습니다. 여러 프로세스가 동시에 뜰 때 로그에 EPERM: operation not permitted, mkdir '...\.claude\.oauth_refresh.lock'이 수십 번 찍히고 매일 아침 다시 로그인해야 했다는 보고(#91708)와, .oauth_refresh.lock.owner.tmp.* 파일이 하루 약 65개씩 811개까지 쌓였지만 아직 기능상 문제는 없었다는 보고(#108764)도 Windows에서 나왔습니다. Windows의 자격 증명은 키체인이 아니라 %USERPROFILE%\.claude\.credentials.json 파일에 저장된다고 보고됩니다.

.credentials.json이나 키체인을 지우거나 재설치해야 하나

이 오류 때문에 .credentials.json이나 macOS 키체인의 Claude Code-credentials 항목을 지울 필요는 없습니다. 공식 문서가 밝히듯 로그인이 거부된 것이 아니라 갱신 순서를 기다리다 멈춘 것이므로, 자격 증명을 지우면 오히려 진짜 로그아웃 상태가 되어 다시 로그인해야 합니다. 다시 로그인이 필요하다면 /login이 저장된 로그인을 새것으로 바꿔 주고, 앞서 본 것처럼 갱신 잠금도 기다리지 않습니다. 자격 증명 파일을 다른 곳으로 옮겨 두라거나 Claude Code를 재설치하라는 조언도 잠금 폴더와는 상관이 없습니다. 지워도 되는 것은 Claude Code 프로세스가 없고 움직이지 않는 것을 확인한 빈 갱신 잠금 폴더 하나뿐입니다.

헷갈리는 다른 메시지: OAuth session expired와 디스크 가득 참

Failed to authenticate: OAuth session expired and could not be refreshed나 Login expired가 뜬다면 잠금이 아니라 갱신 자체가 거부된 경우라서 해결법이 다릅니다. 이 문장들은 Claude unable to authenticate 오류 해결: 로그아웃해도 될 때와 안 될 때에서 다룹니다. 메시지가 Error during compaction: Failed to refresh OAuth token…으로 시작한다면 /compact 도중 같은 잠금에 걸린 것이므로 위 순서대로 푼 뒤, 대화 압축 쪽 처리는 Claude Code compact 오류: Error compacting conversation 메시지별 해결을 참고합니다.

Failed to refresh OAuth token: the disk that holds the Claude Code config directory (~/.claude by default), or your disk quota on it, is full은 앞부분만 같은 다른 오류입니다. 설정 폴더가 있는 디스크나 할당량이 가득 찬 것이므로 필요 없는 파일을 지워 공간을 비운 뒤 다시 보내야 하고, 새 로그인도 저장할 수 없으니 다시 로그인해도 해결되지 않는다고 공식 문서는 설명합니다.