Claude Code에서 「tool call could not be parsed」가 발생하여 작업 내용이 사라질 때, 어떤 버전이 내 환경에서

Claude Code를 사용하다가, 편집 도중에 갑자기 다음과 같은 메시지가 뜨며 멈춘 적이 없으신가요?

The model's tool call could not be parsed (retry also failed)

이 메시지가 나타나면 진행 중이던 Edit나 Bash가 그 자리에서 중단되고, 내부적인 재시도(retry)도 실패하며, 해당 턴(turn)이 통째로 사라집니다. 사용량(usage quota)은 소비되었는데, 정작 손에는 남은 것이 아무것도 없습니다. 가벼운 편집을 요청했을 뿐인데, 작성 중이던 코드까지 함께 사라집니다. 사소해 보이지만, 이는 "알아차렸을 때는 이미 돌이킬 수 없는" 아주 고약한 손실입니다.

이 글은 원인에 대한 해설이 아닙니다 (원인은 기반 시스템 측에 있으며, 사용자 측에서 고칠 수 없습니다). 대신, 이 사고가 자신의 환경에서 어느 정도의 빈도로 발생하는지, 어떤 버전이 안전한지를 자신의 로그를 통해 1분 만에 측정하는 방법을 공유합니다. 데이터 전송은 전혀 하지 않으며, 읽기 전용의 자기 진단 방식입니다.

"내 작성 방식이 잘못된 건가?", "이스케이프(escape) 방식을 바꾸면 고쳐질까?"라고 생각하기 쉽지만, 거의 틀렸습니다.

이 에러는 입력이 68자밖에 되지 않는 Read(내용은 file_path 하나뿐인 경우)에서도 발생합니다. 인수의 크기나 복잡성과 관계없이 확률적으로 발생합니다. 즉, 내용의 문제가 아니라 Claude Code (CLI)가 스트림(stream)으로 전송되는 tool_use의 JSON을 구성하는 부분의 문제입니다. 따라서 프롬프트(prompt)를 아무리 수정해도 근본적으로 줄어들지 않습니다. 이 점이 중요합니다. "특정 버전에서 늘어났다"는 보고가 있습니다. 예를 들어 어떤 보고에서는 CLI 2.1.165에서 실패율이 이전보다 약 8배 급증했다고 수치와 함께 올라와 있습니다 (1.85‰ → 16.4‰).

하지만, 제가 제 로그로 동일한 측정을 해보니, 문제가 되는 버전이 달랐습니다. 제 환경에서는 2.1.165가 오히려 낮았고, 다른 버전(2.1.153이나 2.1.168)에서 높게 나타났습니다.

이것이 의미하는 바는, "이 버전으로 내리면 해결된다"라는 만인을 위한 정답은 없다는 것입니다. OS, 터미널, 사용 방식(병렬 툴 호출량, 확장 사고(extended reasoning) 유무)에 따라 나쁜 버전은 달라집니다. 그러므로 타인이 추천하는 버전을 맹목적으로 내려받는 것이 아니라, 자신의 로그로 자신의 최적 버전을 측정하는 것이 유일하게 믿을 수 있는 방법입니다.

Claude Code는 세션 기록을 ~/.claude/projects/<프로젝트>/<세션ID>.jsonl에 1행 1 JSON 형식으로 남깁니다. 각 메시지에는 사용된 CLI의 version이 포함되어 있으므로, 버전별로 이 에러의 발생률을 집계할 수 있습니다.

다음 스크립트는 그 로그를 읽기만 할 뿐, 어디에도 전송하지 않습니다.

python3 - <<'PY'
import json, glob, os, collections
tot, fail = collections.Counter(), collections.Counter()
...

출력은 다음과 같은 형태가 됩니다 (이는 제 실제 로그의 일부입니다).

version msgs fails per-mille
2.1.140 159162 0 0.00
2.1.153 73842 105 1.42
...

per-mille(천분율)가 해당 버전에서의 "parse 실패 발생 빈도"입니다. 제 경우에는 2.1.153이 유독 나빴고, 2.1.162나 2.1.165는 사실상 제로였습니다. 당신의 로그에서는 완전히 다른 버전이 나쁘게 나올 수도 있습니다. 그래도 괜찮습니다. 중요한 것은 자신의 환경에서 잘 작동하는 버전을 아는 것입니다.

실패율이 낮은 버전으로 고정하기. 최근 버전 중에서 자신의 로그로 per-mille가 낮았던 것에 맞춥니다.

npm i -g @anthropic-ai/claude-code@2.1.162 # 자신의 로그에서 낮게 나왔던 버전으로 교체

그 후 하루 정도 사용해 보고, 다시 위의 스크립트로 재측정하여 확인합니다 ("측정하고, 고정하고, 다시 측정하기").

발생했을 때의 응급 처치. 턴은 사라지지만, 그 직전까지의 작업은 기록에 남아 있습니다. 당황해서 전부 다시 할 필요는 없습니다. 세션을 claude --resume

로 다시 열고 마지막 지시를 한 번 더 내리면, 그때까지의 문맥은 사라지지 않았습니다. -
발생 빈도를 낮추는 작은 팁 (경험칙). 사고(thought)의 effort를 낮추면 발생 빈도가 낮아지는 경우가 있는 것 같습니다 (도구 호출 (tool call) 스트림이 짧고 적어져서, 조립 실패 확률이 낮아진다는 가설). 확증된 대책은 아니므로 어디까지나 보조 수단으로 활용하세요.

같은 「조용히 작업이 사라지는」 계열 중 이보다 더 심각한 것은, 확장 사고 (extended thinking)를 사용한 긴 세션을 resume 하면 400 thinking blocks cannot be modified가 발생하며, 해당 세션을 다시는 열 수 없게 되는 사고입니다. 몇 시간 분량의 대화가 열리는 순간 영구적으로 갇혀버립니다.

이는 기록 (.jsonl) 저장 방식에 원인이 있으며, 손상된 파일로부터 복구 버전을 만들 수 있습니다. 브라우저 내부에서만 (전송하지 않고) 복구 버전을 만드는 도구를 준비해 두었습니다 → Claude Code 세션 구조 도구

이번과 같은 「눈치채지 못하는 조용한 상실」은 에러로 멈춰주는 만큼 그나마 나은 편입니다. 정말 무서운 것은, 도구가 「완료되었습니다」라고 보고했음에도 실제로는 파일이 사라져 있거나 데이터가 조용히 유실되는 유형입니다.

그러한 사고를 실행 직전에 차단하는 무료 훅 (hook) 모음을 공개하고 있습니다 (rm -rf, 강제 push, 비밀 정보 유출, 깨진 배포를 차단하는 예시 다수 수록) → cc-safe-setup

「도구의 보고」가 아니라 「결과물 그 자체」를 스스로 검증하는 습관과, 실제로 발생한 사고를 경험과 방어 절차로 정리한 읽을거리가 Claude Code 사고 방지 핸드북입니다.

요약하자면, tool call could not be parsed는 CLI 측의 리그레션 (regression)이며, 당신의 프롬프트 탓이 아니라 나쁜 버전은 환경마다 다릅니다. 따라서 타인의 추천이 아니라, 자신의 로그로 자신의 최적 버전을 측정하여 고정하는 것이 가장 확실한 대처법입니다. 위의 스크립트는 읽기 전용이므로 안심하고 실행해 보세요.