제 버그 리포트가 틀렸음을 증명한 방법: apiRoot 프록시를 통한 OpenClaw 텔레그램 디버깅

OpenClaw의 Telegram 계정별 apiRoot 설정을 로컬 프록시로 지정하면 실제 와이어 페이로드를 캡처하여 실제 재삽입 버그와 클라이언트 측 렌더링 아티팩트를 구분할 수 있습니다. 한 개발자는 이 방법으로 자신의 버그 보고가 틀렸음을 증명하고 철회했습니다.

버그 보고의 전말

지난주, 메인 에이전트가 주입된 시스템 블록이 포함된 메시지를 받았다며 지시를 거부하기 시작했습니다. 사용자는 이슈 #137927을 제출했습니다. 알고 보니 OpenClaw의 내부 런타임 컨텍스트가 보이는 메시지 텍스트로 누출되어 주입처럼 보였습니다. 세 가지 수정 사항이 병합된 후 이슈는 종결되었지만, 유지관리자들은 이러한 수정이 사용자가 보고한 "깨끗한 텍스트에 전체 블록 재삽입" 증상을 해결하지 못했다고 언급했습니다. 관련 이슈 6개가 여전히 열려 있습니다.

증거가 약했던 이유

사용자가 HTML을 제거하고 깨끗한 텍스트를 복사하여 다시 테스트했을 때 구분 기호가 다시 나타났습니다. 한 댓글 작성자는 이것이 모델 에코, 재생 오염, 클라이언트 렌더링 또는 실제 채널 재삽입의 네 가지 가능성이 있다고 지적했습니다. 사용자의 증거(채팅 클라이언트에서 붙여넣은 텍스트)는 이를 구분할 수 없었습니다. 열한 개의 스레드 중 누구도 실제 전송된 페이로드를 캡처하지 못했습니다.

와이어 페이로드 캡처

OpenClaw의 Telegram 구성에는 계정별 apiRoot가 있습니다. 이를 로컬 로깅 프록시로 지정하면 해당 계정의 API 호출이 Telegram 대신 프록시를 통해 전달됩니다. 단계:

• BotFather에서 임시 봇을 만듭니다.
• 구성에서 두 번째 Telegram 계정으로 추가하고 동일한 에이전트에 바인딩합니다.
• 해당 계정의 apiRoot만 로컬 로깅 프록시로 설정합니다.
• 프록시가 요청 본문을 기록하고 api.telegram.org로 전달한 후 응답을 반환합니다.
• 프로덕션 계정은 실제 토큰과 기본 apiRoot를 유지하며 다른 것은 이를 통해 라우팅되지 않습니다.

약 120줄의 stdlib Python으로 프록시를 구현할 수 있습니다.

결과

테스트 1: 구분 기호가 없는 일반 산문. 와이어 페이로드는 완전히 깨끗했습니다. 그러나 에이전트의 응답은 입력이 전체 런타임 컨텍스트 블록과 함께 도착했다고 언급했습니다. 즉, 출력이 깨끗해도 블록은 모델에 도달합니다.

테스트 2: 사용자가 제거된 전문 텍스트를 보냈습니다. 와이어 페이로드에는 <<<BEGIN_OPENCLAW_INTERNAL_CONTEXT>>> (HTML 이스케이프됨)가 표시되었지만, 복사된 것은 리터럴 <<<BEGIN\_OPENCLAW\_INTERNAL\_CONTEXT>>>였습니다. 리터럴 구분 기호는 전송되지 않았습니다 — 에이전트가 블록을 설명하면서 인용하고, OpenClaw가 HTML 이스케이프(parse_mode가 HTML)하여 Telegram이 다시 리터럴 문자열로 렌더링하고, 복사하면 이스케이프되지 않은 버전이 나온 것입니다.

결론

버그 보고서에 붙여넣은 모든 대화록은 이미 렌더링 및 복사를 거쳤으므로 전송과 인용을 증명할 수 없습니다. 여러 보고서가 이러한 약한 증거에 기반하고 있습니다. 이 디버깅 방법이 더 신뢰할 수 있음을 보여줍니다. 또한 수정 사항을 읽는 동안 사용자는 더 심각한 별도의 아키텍처 문제를 발견했으며, 이를 별도로 보고할 계획입니다.