• Claude의 데스크톱 앱(Cowork 모드)에서,
  **로컬 Mac을 조작하는 자동화 (Computer use)**를 실행했다. - 모델로
  Opus 5를 사용하던 중, 도중에 The model's tool call could not be parsed (retry also failed).

가 반복적으로 발생하여 더 이상 진행할 수 없게 되었다. Opus 4.8로 전환했더니, 동일한 절차로 마지막까지 정상적으로 완주했다. - 원인 분석 결과,
「Computer use의 권한 설정」 문제는 아니었다. 에러의 정체는 모델이 출력한 툴 호출(tool call)을 시스템이 구문 분석(parsing)할 수 없었다는, 모델 출력 측의 문제였다. - 대처법은 「다른 모델로의 전환」이 확실하다.

사내 관리 업무로, 매월 청구서 작성을 자동화하고 있다. 대략적인 흐름은 다음과 같다.

• 미리 준비한 베이스 PDF를 Python 스크립트로 가공 (날짜·제목의 연월·청구서 번호 등, 매달 바뀌는 부분만 교체)
• 생성된 청구서 PDF를 검증 (전월분과의 차이가 예상대로인지)

Computer use로 GUI 조작: Finder 상의 .command

(메일 초안 작성 스크립트)를 더블 클릭하여, 메일 앱에 송부용 초안을 만들게 함

이 세 번째 단계가 이른바 **Computer use (AI에게 마우스·키보드·스크린샷을 사용하게 하여 실제 GUI를 조작하게 하는 기능)**에 해당한다.

• Claude 데스크톱 앱의 Cowork 모드
• 처리 본체 (PDF 생성·검증)는
  클라우드의 샌드박스 (sandbox) 상에서 실행
• GUI 조작 대상은
  수중의 Mac (로컬). 디바이스 연동 (bridge)을 통해 클라우드 측의 AI로부터 로컬 앱을 조작하는 구성
• macOS 측에서는 대상 앱 (Finder / 메일 / 터미널)에 대한 조작 허가를 실행 시 다이얼로그로 승인하는 메커니즘

Opus 5로 실행하고 있으면, GUI 조작 단계에 들어갔을 즈음 다음 메시지가 나오며 정지했다.

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

시스템 측에서도 다음과 같이 재촉한다.

The previous response failed to produce a valid tool call. Please retry the tool call now.

리트라이(retry)를 해도 마찬가지. 몇 번을 실행해도 동일한 지점에서 막히는 상태였다.

이 부분이 이번에 가장 전달하고 싶은 포인트다.

처음에는 「Opus 5에서는 Computer use를 허용하는 설정이 어딘가에 있고, 그것을 ON으로 하지 않은 것이 아닐까?」라고 의심했다. 하지만, 로그를 다시 확인하니 Opus 5에서도 Computer use 자체는 작동하고 있었다.

구체적으로는, 막히기 전의 다음 툴 호출은 모두 성공했었다.

• 앱의 액세스 권한 해결 및 취득 (Finder / 메일 / 터미널의 조작 허가)
• Finder 실행
• 스크린샷 취득

실패한 것은 그 이후의 「Finder 내 특정 위치를 클릭하는」 툴 호출을 생성하는 바로 그 순간뿐이었다.

즉,

만약 Computer use가 「권한에 의해」 차단된 것이라면, 그 이전의 허가 취득이나 스크린샷도 작동하지 않았을 것이다.

실제로 작동하고 있었다. 따라서 이것은 권한·설정의 문제가 아니다.

라고 결론 내릴 수 있다. macOS의 개인정보 보호 설정 (시스템 설정 → 개인정보 보호 및 보안)과는 별개의 레이어 이야기다.

Opus 5인 상태로 몇 번을 리트라이해도 고쳐지지 않았기에, 모델을 Opus 4.8로 전환하여 동일한 처리를 재실행했다.

결과,

• Finder에서 목적의 폴더로 이동
• .command를 더블 클릭
• 터미널에서 AppleScript가 실행되어 메일 앱 초안에 2건 생성

까지, 한 번도 막히지 않고 완주했다. 처리 내용 (스크립트도 GUI 조작 순서도)은 Opus 5 때와 완전히 동일하다. 차이점은 모델뿐이다.

The model's tool call could not be parsed는

결국

모델이 출력한 툴 호출 (function call)을 시스템 측에서 구문(syntax)으로서 읽어낼 수 없었다는 뜻이다.

라는, 모델의 출력 포맷(output format) 측의 결함을 나타낸다. 사용자가 토글로 활성화하는 종류의 설정이 아니다.

이번 경우,

• Computer use의 툴 모음(스크린샷, 클릭, 앱 실행 …)은
  스키마(schema)가 비교적 복잡함 - 그중
  특정 툴 호출(tool call) 생성 시에만 재현됨 - 다른 모델로 바꾸면 재현되지 않음

이라는 상황으로부터, Opus 5와 툴 호출 시리얼라이제이션(serialization) 사이의 맞물림 문제로 발생한 결함이라고 보는 것이 자연스럽다고 생각한다. ※ 어디까지나 외형적인 관찰에 기반한 추측이며, 내부 원인을 단정하는 것은 아니다.

• tool call could not be parsed가 나오면, 우선 모델을 의심하라 - 「Computer use를 허용하는 모델 설정」은 존재하지 않는다. 전 단계의 툴 호출(권한 획득·스크린샷 등)이 통과되었다면, Computer use 자체는 차단되지 않은 것이다. - 문제 분리의 핵심은 **「어느 툴 호출까지 성공했고, 어디서 실패했는가」**이다. 전부 실패한다면 권한·연결 문제, 중간까지 작동하다 특정 단계에서 실패한다면 출력 측(즉, 모델)을 의심하라. - 재현되는 경우에는 해당 응답의 저평가(👎) 버튼을 통해 피드백을 보내면, 이러한 종류의 툴 호출 결함 개선에 도움이 된다. 권한 설정을 찾아 헤매기 전에, 다른 모델(이번에는 Opus 4.8)로 전환하여 재실행하는 것이 가장 빠르다.

동일한 절차·동일한 환경에서, 모델을 바꾼 것만으로 해결되었다. 에러 메시지에 휘둘려 권한 설정을 찾기보다, 모델 전환으로 문제를 분리하는 것이 빠르다는 하나의 사례이다.