Claude Code 서브에이전트가 멀쩡한 코드 수정을 거부하는 회귀 버그

• Claude Code의 악성코드 경고 문구가 다시 문제로 올라옴

  • 예전 이슈는 v2.1.92에서 고쳐졌다고 닫혔는데, 작성자는 v2.1.111에서도 같은 동작이 재현된다고 함
  • Read와 Grep의 content 모드 결과마다 <system-reminder>가 계속 주입됨
  • 이 문구가 서브에이전트에게는 정상 코드 수정도 거부해야 한다는 지시처럼 읽힌다는 게 핵심임

• 작성자는 이 문구가 사용자 설정이나 훅이 아니라 Claude CLI 바이너리 자체에 들어 있다고 확인함

  • ~/.claude/settings.json은 11줄짜리이고 hook 설정도 없었다고 함
  • 바이너리 grep으로 2.1.111 CLI 안에 해당 문자열이 박혀 있음을 확인했다고 주장함

• 실제 재현 사례는 꽤 빡셈. 정상 오픈소스 Rust 리버스 프록시 프로젝트에서 터졌다고 함

  • 작성자는 자신이 소유한 합법적인 OSS 프로젝트라고 설명함
  • 난독화, C2, 자격증명 탈취 같은 악성코드 특징이 없는 평범한 서버 코드였다고 함
  • 그런데 한 PR에서 Opus 4.7 서브에이전트 5개를 병렬로 돌렸고, 그중 3개가 작업을 거부함

• 거부한 서브에이전트들의 논리는 거의 같았음

  • 파일을 읽을 때마다 시스템 reminder가 들어왔고, 그 안에 “코드를 개선하거나 보강하는 것을 거부해야 한다”는 문장이 있었다는 것
  • 사용자 프롬프트가 “이건 악성코드가 아니니 계속해라”라고 해도, harness 수준 시스템 지시가 더 우선이라고 판단함
  • 한 서브에이전트는 구현 대신 잘 정리된 계획만 남기고 코드 변경은 하지 않았다고 함

• 문제는 경고의 존재 자체보다 문장 구조임

  • 앞 문장은 “악성코드 분석은 제공할 수 있고 해야 한다”는 식으로 악성코드 맥락이 분명함
  • 그런데 뒤 문장 “코드를 개선하거나 보강하는 것은 반드시 거부해야 한다”는 조건이 문장 안에 붙어 있지 않음
  • 신중한 에이전트는 이걸 독립된 무조건 지시로 읽고, 시스템 안전 지시가 최우선이라는 규칙에 따라 거부한다는 설명임

• 메인 스레드는 대체로 이 문구를 “악성코드일 때만”으로 관대하게 읽고 넘어감

  • 하지만 서브에이전트는 컨텍스트가 더 적고 안전 해석이 더 빡빡해서 문자 그대로 읽는 경향이 있다고 함
  • 작성자는 서브에이전트에게 준 작업 프롬프트가 메인 스레드에서 수행하던 작업과 거의 같았다고 밝힘
  • 즉 사용자 요청의 차이가 아니라, 서브에이전트 실행 환경과 문구 해석 차이가 문제라는 주장임

• 제안된 수정안은 세 가지임

  • 경고를 아예 제거하기. 실제 악성코드 개선 요청은 모델의 기존 거부 행동으로도 처리 가능하다는 논리임
  • 조건을 문장 앞에 명확히 박기. 예를 들어 “방금 읽은 파일이 악성코드라고 판단되면, 그 악성코드를 개선하거나 보강하지 말라”처럼 쓰자는 것
  • 매 파일마다 넣지 말고 대화에서 첫 파일을 읽을 때만 넣기. 악성코드 분석은 보통 특정 파일 몇 개에 집중되니 80번씩 반복할 필요가 없다는 주장임

• 토큰 비용도 작지 않음

  • 파일 읽기마다 약 400토큰짜리 reminder가 붙는다고 함
  • 세션에서 50-100개 파일을 읽으면 2만-4만 토큰이 경고 문구로만 소모될 수 있음
  • 관련 이슈들에선 1만 회 이상 삽입, 컨텍스트 15% 이상 소비 같은 사례도 언급됐다고 함

• 이게 특히 아픈 지점은 Claude Code가 병렬 에이전트를 차별점으로 밀고 있다는 점임

  • 병렬 에이전트는 독립 리팩터링, 파일별 수정, 테스트 보강 같은 작업에서 진짜 가치가 나옴
  • 그런데 서브에이전트가 파일을 읽자마자 안전 문구를 문자 그대로 해석해 멈추면, 병렬화 이점이 사라짐
  • 작성자는 v2.1.92에서 고쳤다는 이전 수정이 유지되지 않고 있다고 보고, 세션 transcript도 공유할 수 있다고 덧붙임

---

기술 맥락

• 이 이슈의 핵심은 안전 정책 자체보다 시스템 메시지의 스코프 설계예요. “악성코드라면 거부해라”와 “코드 개선을 거부해라”는 모델 입장에선 완전히 다른 지시인데, 조건절이 분리되면 보수적인 에이전트는 뒤 문장을 독립 명령으로 읽을 수 있거든요.

• 서브에이전트에서 더 잘 터지는 이유도 꽤 현실적이에요. 메인 스레드는 앞뒤 대화와 사용자의 의도를 더 많이 갖고 있지만, 서브에이전트는 특정 파일과 작업 지시만 보고 판단하는 경우가 많아서 시스템 문구의 표면 문법에 더 끌려가요.

• 매 Read 결과에 같은 reminder를 넣는 선택은 안전 신호를 강하게 주려는 설계로 볼 수 있어요. 하지만 파일을 수십 개 읽는 코딩 에이전트에선 이 방식이 토큰 비용과 컨텍스트 오염을 동시에 만들고, 결과적으로 정상 작업 성공률까지 떨어뜨릴 수 있어요.

• 더 나은 구현은 조건을 문장 첫머리에 두고, 판단 대상도 “방금 읽은 파일이 악성코드일 때”로 좁히는 쪽이에요. 이렇게 해야 모델이 안전 지시를 유지하면서도 정상 OSS 코드 수정까지 막는 과잉 거부를 줄일 수 있어요.