NanoClaw Telegram 봇이 응답하지 않을 때 첫 번째 조치는 해결책을 적용하는 것이 아니라 인바운드 메시지가 호스트에 실제로 도달하는지 판단하는 것입니다. 별도로 보고된 두 NanoClaw 장애가 서로 반대되는 징후로 동일한 문제를 일으키기 때문입니다. 한 경우에는 인바운드가 중단되지만 아웃바운드 전송과 예약 작업은 계속 작동하므로 운영자가 확인하는 모든 표면이 정상처럼 보입니다. 다른 경우에는 아무것도 전송되지 않으며 로그에는 실제로 전송되지 않은 메시지가 delivered로 표시됩니다. 같은 문제 제기라도 원인은 다르며, 한쪽의 해결책은 다른 쪽에 아무 효과가 없습니다.
무엇보다 먼저 한 가지를 구분해야 합니다. 이 문구에 대한 검색 결과는 대부분 다른 제품에 관한 것이기 때문입니다. OpenClaw는 별개의 훨씬 큰 프로젝트로, 2026년 9월 21일 저장소 API 레코드를 확인했을 때 별 390,207개와 NOASSERTION 라이선스를 보유하고 있었으며 NanoClaw 자체 홈페이지도 OpenClaw와 대비하여 자신의 입지를 설명합니다. NanoClaw는 nanocoai/nanoclaw입니다. MIT 라이선스이고, 보관되지 않았으며, fork가 아니고, 별 30,818개와 열린 이슈 1,068개를 보유하며, 마지막 푸시는 2026년 9월 19일이었습니다(GitHub API, 같은 날짜). 이전 qwibitai/nanoclaw 주소는 301로 이 주소로 연결되므로 이름이 변경된 동일 프로젝트이지 두 번째 프로젝트가 아닙니다. 두 프로젝트는 Telegram 코드 경로를 공유하지 않습니다. NanoClaw는 channels 브랜치에서 소스 코드를 복사하여 자체 어댑터를 설치합니다(add-telegram 스킬). 따라서 OpenClaw의 해결책은 그대로 적용할 수 없습니다. 전체 차이는 NanoClaw와 OpenClaw 비교를 참조하세요.
무엇이 보이는지 확인한 뒤 조치하세요
아래의 각 행은 자체 확인 절차가 있는, 서로 별개로 보고된 장애입니다. 8개 항목 모두 2026년 9월 21일 NanoClaw의 자체 이슈 추적기, 제공된 스킬 및 채널 문서에서 확인했습니다.
| 관찰되는 현상 | 가장 가능성 높은 원인 | 확인 방법 |
|---|---|---|
| 보내는 메시지에는 답이 없지만 답장, 예약 메시지 및 아웃바운드 전송은 계속 작동함 | 폴링 루프가 실패한 뒤 영원히 재시도 중 — 이슈 #3728, 열려 있음 | 큰 consecutiveFailures 값을 전달하는 Telegram polling request failed 행. 성공 시 로그가 기록되지 않으므로 조용한 로그가 정상 작동의 증거는 아님 |
아무것도 전송되지 않으며, 주 로그에 Message delivered와 함께 platformMsgId=undefined가 No adapter for channel type 옆에 표시됨 | 호스트 인스턴스가 동시에 두 개 실행 중 — 두 번째 폴러가 Telegram에서 409를 받아 어댑터가 등록되기 전에 설정을 중단함(/debug 스킬, PR #2225) | telegram에 대한 Channel adapter started 행이 없고, ps aux에 두 번째 프로세스가 있음 |
| 개인 메시지와 그룹은 작동하지만 채널 게시물은 전혀 도착하지 않음 | 봇 토큰에 남아 있는 오래된 서버 측 업데이트 필터 — 이슈 #2989, 열려 있음 | 이 토큰이 이전에 NanoClaw v1 또는 다른 봇 라이브러리로 폴링된 적이 있나요? Telegram 자체 Bot API는 allowed_updates에 대해 다음과 같이 설명합니다. "지정하지 않으면 이전 설정이 사용됩니다." |
| 봇이 개인 메시지에는 답하지만 일반 그룹 텍스트는 무시함 | Group Privacy가 켜져 있음(add-telegram 스킬) | BotFather, /mybots, Bot Settings, Group Privacy — 이후 봇을 그룹에 다시 추가 |
| 메시징은 작동하지만 페어링이 완료되지 않음 | 부팅 시 getMe가 한 번 실패했고 null 봇 사용자 이름이 프로세스 수명 동안 캐시됨 — 이슈 #3162, 열려 있음 | 페어링 시도 몇 분 전 부팅 때 Telegram getMe failed 경고가 한 번 기록됨. 이슈에 따르면 재시작하면 해결됨 |
| "Couldn't reach Telegram"과 함께 설정이 중단되거나 시작이 약 1분 30초 동안 멈춤 | 작동하는 경로 없이 IPv6가 구성됨 — 이슈 #2377, 열려 있음 | curl -4는 Bot API에 성공하지만 curl -6는 연결하지 못함 |
| 대부분의 답장은 도착하지만 특정 URL이 포함된 답장은 절대 도착하지 않음 | 수신이 아니라 아웃바운드 형식 문제입니다. 이슈 #3569는 고정된 어댑터가 이스케이프되지 않은 마커의 개수가 홀수인 메시지를 잘라낸다고 보고합니다. | Telegram이 전송을 거부합니다. 밑줄 하나가 포함된 URL 두 개가 서로 상쇄되어 간헐적인 문제처럼 보입니다. |
| 방금 추가한 두 번째 봇이 온라인 상태가 되지 않음 | 인스턴스 변수는 시작 시 한 번 읽히며 중복 토큰은 건너뜀(채널 문서) | logs/nanoclaw.error.log에 경고가 있음(add-telegram 스킬). Telegram은 토큰당 폴러 하나만 허용하므로 봇마다 자체 BotFather 토큰이 필요함 |
NanoClaw의 공식 1차 진단 절차는 두 개의 로그 파일과 ncl sessions list, ncl dropped-messages list 및 ncl wirings list입니다. 릴리스된 버전에는 채널 생존 여부를 확인하는 명령이 없으므로 아래의 분류는 대신 로그 행에 의존합니다.
# 1. Is inbound polling failing, and for how long?
# A rising consecutiveFailures count is the #3728 signature.
grep "Telegram polling request failed" logs/nanoclaw.error.log | tail -5
# 2. Did the Telegram adapter ever register this boot?
# Its ABSENCE is the duplicate-host signature, not an error line.
grep "Channel adapter started" logs/nanoclaw.log | tail -10
# 3. Is a second host holding the polling session?
ps aux | grep 'nanoclaw/dist/index.js' | grep -v grep
systemctl --user list-units 'nanoclaw*' --all # Linux systemd installs인바운드가 중단되어도 모든 것이 정상처럼 보이는 이유
이는 구조적인 문제이며 가장 많은 시간을 낭비하게 만드는 부분입니다. NanoClaw의 README는 메시징 앱에서 호스트 라우터로, 인바운드 데이터베이스로, 컨테이너 안으로, 아웃바운드 데이터베이스로, 다시 전송 경로로 돌아오는 흐름을 설명합니다. 전송은 자체적으로 아웃바운드 데이터베이스를 폴링하고, 60초마다 실행되는 호스트의 순회 점검은 전송 시각이 된 메시지와 반복 메시지를 독립적으로 깨웁니다. 인바운드는 Telegram 폴러에 의존하는 유일한 단계입니다. 이것이 이슈 #3728의 제보자가 약 4일 동안 인바운드가 완전히 끊겼는데도 호스트가 활성 상태를 유지하고, 아웃바운드 전송이 계속 작동하며, 예약 작업도 계속 실행되는 것을 보게 된 이유입니다. 연속 실패 횟수는 11,178회로 기록되었습니다.
이를 포착했어야 할 상태 확인 hook도 작동하지 않습니다. NanoClaw가 게시한 어댑터 인터페이스 참조는 isConnected()에 대해 "현재 테스트 외에는 호스트에서 호출되지 않는다"고 하며, "bridge는 항상 true를 반환한다"고 설명합니다. 이후 trunk는 변경되었습니다. 어댑터별 연결 상태를 보고하는 ncl status 명령이 v2.3.0 릴리스 이후인 2026년 9월 15일 main에 추가되었습니다. 따라서 해당 문서는 모든 릴리스 버전에 대해서는 정확하지만 trunk에 대해서는 오래된 상태입니다. 이 명령은 숨김 및 호스트 전용으로 등록되어 있고 어떤 문서에도 나타나지 않으므로 출시되지 않은 내부 기능으로 취급하고 조언으로 사용하지 마세요. Telegram의 경우 결국 두 경로는 만납니다. 어댑터의 4.29.0과 4.41.0 어느 쪽도 isConnected를 구현하지 않습니다(이 페이지를 위해 두 dist 빌드에서 모두 검색함). 따라서 어느 쪽에서도 probe는 true로 대체됩니다.
문서에는 대응되는 공백이 있습니다. 문제 해결 페이지에는 "Webhook channel is silent"라는 제목의 섹션과 폴링에 해당하는 내용이 없고, "Agent never replies" 안내는 ncl dropped-messages list와 함께 "Did the router accept it?"에서 시작합니다. 이는 이미 메시지가 호스트에 도달했다고 가정하는 단계입니다. 폴러가 중단된 경우에는 라우터가 메시지를 본 적이 없으므로 삭제된 메시지 행을 찾을 수 없습니다. Issue #2989도 자체 원인에 대해 같은 막다른 상황을 기록합니다. 로그 행도, 삭제된 메시지 행도 없으므로 디버깅할 대상이 없습니다.
수정 버전이 없으므로 그에 맞춰 계획하세요
Issue #3728은 댓글 0개, 라벨 0개, 마일스톤 없음 상태로 열려 있으며, 업데이트 시각도 2026년 9월 6일 생성 시각과 여전히 같습니다. 최신 릴리스는 2026년 8월 24일의 v2.3.0이고, 9월 1일 이후 channels 브랜치에 있는 유일한 커밋은 Mattermost 수정입니다. 오래된 필터 사례도 마찬가지입니다. 명시적인 업데이트 목록을 고정할 풀 리퀘스트는 2026년 8월 22일 이후 channels를 대상으로 열린 상태이며, 현재 브랜치 소스에는 allowedUpdates가 전혀 나타나지 않습니다. 중복 호스트 사례를 방지했을 단일 인스턴스 호스트 잠금은 병합되지 않은 채 종료되었습니다. 따라서 정직한 표현은 버전 번호가 아니라 완화책입니다.
직접 패치를 작성하기 전에 알아두어야 할 세 가지가 있습니다. 첫째, src/channels/telegram.ts를 로컬에서 수정해도 그 변경 사항은 유지되지 않습니다. add-telegram 스킬은 channels 브랜치가 기준 원본이므로 덮어쓰라는 지침에 따라 해당 브랜치에서 그 파일을 복사해 오고, update 스킬은 설치된 모든 채널을 갱신합니다. 바로 이 때문에 #3728 제보자는 업데이트할 때마다 해당 수정 사항을 잃었습니다. 둘째, 제보자의 워치독은 구현 방법인 동시에 경고이기도 합니다. 카운터만 사용하는 첫 번째 버전은 더 심각한 3일간의 서비스 중단을 초래했습니다. 폴러가 실패하는 대신 중지된 상태가 되었기 때문에 추가 실패가 기록되지 않았고, 카운터는 임계값에 도달하지 못했습니다. 두 번째 버전은 서로 독립적인 두 가지 신호를 사용했으며 폴러를 중지된 상태로 두지 않았습니다. 이 중 어느 것도 정식으로 제공되거나, 공식적으로 권장되거나, 독립적으로 검증된 것이 아닙니다. 셋째, 무엇을 구현하든 양방향의 복구를 테스트하세요. 발신 성공은 수신에 대해 아무것도 입증하지 못하므로, 중요한 확인 방법은 연동된 채팅에서 새 메시지를 보내 새 수신 행이 생성되는지 확인하는 것입니다.
Telegram 채널 장애는 모델 또는 API 문제가 아닙니다
이 점은 분명히 밝혀둘 필요가 있습니다. 다음에 사람들이 하는 명백한 검색이 잘못된 방향으로 이끌기 때문입니다. NanoClaw의 credentials documentation에 따르면 TELEGRAM_BOT_TOKEN 같은 채널 토큰은 .env에 저장되어 호스트 프로세스가 사용하며, 컨테이너는 사용하지 않습니다. 반면 모델 자격 증명은 볼트에 저장되고 요청을 외부로 보내는 동안 주입됩니다. 인바운드 메시지는 공급자를 선택하기 전에 라우터와 세션의 인바운드 데이터베이스에 도달합니다. 공급자는 컨테이너가 생성될 때 확인되기 때문입니다(agent providers documentation). 기본 URL, 키, 게이트웨이 또는 공급자를 바꿔도 중단된 폴링 루프, 오래된 업데이트 필터, 폴러 충돌, Group Privacy 또는 고장 난 IPv6 경로는 복구되지 않습니다.
진정한 교차 지점은 반대 방향으로 작동합니다. NanoClaw의 README는 모든 /customize, /debug 및 /add-channel 스킬에 Claude Code가 필요하다고 명시하므로, 에이전트 그룹을 다른 곳에서 실행하더라도 채널을 복구하려면 호스트에 Claude Code가 있어야 합니다. 호스트 요구 사항은 macOS 또는 Linux, WSL2를 통한 Windows, Node.js 22 이상, pnpm 10 이상 및 Docker입니다. 또한 nanoclaw.dev는 여전히 Node.js 20 이상을 광고하지만 README와 v2.3.0 변경 로그는 22를 최소 요구 버전으로 명시합니다. 버전 상향을 호환성을 깨는 변경이라고 부르는 변경 로그를 기준으로 하세요.
NanoClaw와 Telegram 채널의 실제 비용
| 항목 | 비용 | 출처 |
|---|---|---|
| NanoClaw 자체 | $0, MIT 라이선스, 유료 등급 없음, 사용자 계정 없음 | nanoclaw.dev: "NanoClaw는 MIT 라이선스로 제공되는 무료 오픈 소스입니다." |
| 커뮤니티 포털 계정 | 무료이며 선택 사항입니다. 그 외의 모든 기능은 계정 없이 작동합니다 | 프로젝트 README |
| Telegram 봇 토큰 | BotFather에서 생성하는 데 $0이며, 연결된 채팅 하나에는 구매할 것이 없습니다. Telegram의 선택적 Paid Broadcasts 등급은 초당 30개 메시지를 초과하는 경우에만 적용됩니다 | Telegram Bot API; 채널 문서에 따르면 폴링 모드에서는 공개 URL, 웹훅 또는 열린 포트도 필요하지 않습니다 |
| 모델 사용량 | 연결된 공급자가 청구하는 금액에 따릅니다. NanoClaw 자체는 이에 대해 아무것도 청구하지 않습니다 | nanoclaw.dev FAQ: "이용하는 에이전트 제공업체가 모델 사용에 대해 요금을 부과할 수 있습니다." |
| Docker | 호스트에 필요하며, Docker의 자체 구독 약관은 무료 사용 한도를 초과할 때 적용됩니다 | 이 페이지에서는 확인하지 않았습니다. 예산을 세우기 전에 Docker의 가격 페이지를 읽으세요 |
응답하지 않는 봇을 해결하기 위해 구매할 유료 등급은 없습니다. 이 표가 알려주는 유용한 사실은 바로 그것입니다. 비용이 발생하기 시작하는 시점은 채널이 다시 작동하고 에이전트가 응답한 뒤입니다. 아래 수치는 측정된 작업 비용도 청구서 상한도 아닌, 예시적인 토큰 산술입니다. 연결된 채팅 하나가 하루 25턴, 턴당 캐시되지 않은 입력 토큰 20,000개와 출력 토큰 900개를 사용하고, 이를 30일 동안 지속한다고 가정합니다. 요금은 백만 토큰당 Kunavo 카탈로그의 현재 가격입니다.
| 모델 | 1M당 입력 / 출력 | 예상 월 비용 |
|---|---|---|
| Claude Haiku 4.5 | $0.70 / $3.50 | $12.86 |
| GPT-5.6 Terra | $0.70 / $4.20 | $13.34 |
| Claude Sonnet 4.6 | $2.10 / $10.50 | $38.59 |
| Claude Opus 5 | $3.50 / $17.50 | $64.31 |
예산으로 간주하기 전에 자체 트래픽에 맞춰 계산을 조정하고, 가장 큰 영향을 미치는 가정에 유의하세요. 아무것도 캐시에서 제공되지 않는다는 가정입니다. 장시간 유지되는 에이전트 세션은 컨텍스트를 다시 전송하므로, 캐시 동작이 인접한 두 모델 간 토큰당 가격 차이보다 이 수치를 더 크게 움직입니다. Kunavo 카탈로그 금액은 상한이 아니라 청구 하한입니다. 업스트림에서 요금을 보고하면 청구액은 카탈로그 비용과 업스트림 비용에 해당 마크업을 곱한 금액 중 더 큰 금액이 됩니다. 최소 충전액은 $10 선불 크레딧이며, 이는 작업 수수료나 구독료가 아니라 자금 충전 최소액입니다. 결제 세부 정보를 참조하세요.
| 에이전트 모델의 라우팅 | 유리한 경우 | 이것이 하지 않는 일 |
|---|---|---|
| 공급자 직접 API | 한 공급자의 플래그십 모델을 계속 사용하고 해당 공급자의 자체 캐싱 및 배치 약관을 원합니다 | 두 번째 공급자는 두 번째 계정과 두 번째 잔액을 의미합니다 |
| OpenAI 호환 또는 Anthropic 호환 게이트웨이 | 에이전트 그룹별로 모델을 전환하고 하나의 키와 하나의 잔액을 원합니다 | NanoClaw의 기본 공급자는 Claude Agent SDK이므로, 사용자 지정 기본 URL은 해당 와이어 형식을 사용해야 합니다. OpenAI 형식 엔드포인트는 OpenCode 공급자 스킬을 통해 접근하며, 이 스킬은 OpenCode 자체 설정을 통해 모델을 라우팅합니다 |
| 구독 | 사용량에 따른 토큰 요금보다 정액제의 높은 일일 사용량이 더 적합합니다 | NanoClaw는 자체 구독을 판매하지 않으며, 정액제는 공급자에 속합니다 |
| 로컬 모델 | 호스팅 모델 비용 없이 소규모 또는 비공개 작업을 수행합니다 | NanoClaw 자체 Ollama 스킬은 오래된 설정 경로를 대상으로 설명되어 있으며, 현재 main에서 지원되는 드롭인 전환 기능은 아닙니다 |
이 네 가지 선택지 중 어느 것도 Telegram 경로에 영향을 주지 않습니다. 공급자 측 전체 내용, 즉 설정에서 읽는 두 환경 변수, 컨테이너가 실제로 보는 값, OpenCode와 Codex가 들어가는 위치는 NanoClaw API costs and providers를 참조하세요. 기본 Claude 런타임을 사용자 지정 엔드포인트에 연결하는 경우 Claude Code integration guide와 base URL reference에서 설정을 다루며, 키에 자금을 충전할 준비가 되면 create a Kunavo account를 이용할 수 있습니다. Kunavo는 NanoClaw을 런타임에서 테스트하지 않았으며, 게시된 설정 안내는 호환성 테스트가 아니라 설정 참고 자료입니다.
자주 묻는 질문
NanoClaw Telegram 봇이 응답하지 않는 이유는 무엇인가요?
먼저 메시지가 호스트에서 계속 나가고 있는지 확인하세요. 답장과 예약 메시지는 계속 도착하지만 사용자가 보내는 메시지에는 아무 응답도 없다면 인바운드 폴링이 의심됩니다. NanoClaw 이슈 #3728에 따르면 어댑터의 폴링 루프는 30초 백오프 상한으로 getUpdates를 계속 재시도하고, 포기하지 않으며, 성공적인 폴링에서는 아무것도 기록하지 않으므로 장애가 보이지 않습니다. 아무것도 전송되지 않고 로그에 platformMsgId=undefined가 포함된 "Message delivered" 항목과 "No adapter for channel type" 경고가 함께 표시된다면 NanoClaw의 자체 /debug 스킬은 동시에 실행 중인 두 서비스 인스턴스를 원인으로 지목합니다. 두 경우의 해결책은 서로 반대이므로 무엇이 발생했는지 확인한 뒤 변경하세요.
NanoClaw Telegram 폴링 버그의 수정 버전이 있나요?
2026년 9월 21일 현재는 없습니다. 이슈 #3728은 댓글 0개, 라벨 0개, 마일스톤 없음 상태로 열려 있으며, 업데이트 시각도 등록일인 2026년 9월 6일과 같습니다. 최신 NanoClaw 릴리스는 2026년 8월 24일의 v2.3.0이므로 해당 보고 이후 배포된 것은 없고, 9월 1일 이후 channels 브랜치의 유일한 커밋은 Mattermost 수정입니다. 이 문제를 해결하려면 특정 NanoClaw 버전으로 업그레이드하라고 말하는 사람은 존재하지 않는 버전을 지칭하는 것입니다.
@chat-adapter/telegram을 업그레이드하면 해결되나요?
무응답 경로에는 해결책이 아닙니다. NanoClaw는 @chat-adapter/telegram을 정확히 4.29.0으로 고정하고 있으며, 이 버전은 2026년 5월 18일에 게시되었습니다. npm의 최신 dist-tag는 2026년 9월 18일의 4.41.0입니다. 이 페이지를 위해 두 tarball을 모두 내려받아 비교했습니다. getUpdates 전송 실패 분기는 두 빌드에서 본질적으로 동일합니다. 동일한 consecutiveFailures 카운터, 동일한 30초 백오프 상한, 동일한 경고 문구, 포기 또는 상위 단계 전파 없음, 성공적인 폴링에서도 여전히 로그가 기록되지 않습니다. 4.41.0은 루프의 다른 부분을 다시 작성했습니다. 이 페이지는 이를 코드에 관한 사실로 설명할 뿐 pin을 올리라고 권장하지 않습니다. NanoClaw의 add-telegram 스킬은 공급망 정책상 범위 지정 버전을 거부한다고 설명하고, 이 페이지를 위해 확인한 두 개의 bump 풀 리퀘스트(#3460 및 #3570)는 열려 있지만 병합되지 않았으며, 여기서는 bump로 인해 달라지는 다른 사항을 테스트하지 않았습니다.
API 공급자나 기본 URL을 변경하면 Telegram 문제가 해결되나요?
아니요. NanoClaw의 자격 증명 문서에 따르면 TELEGRAM_BOT_TOKEN 같은 채널 토큰은 .env에 저장되어 호스트 프로세스에서 사용되며 컨테이너에서는 사용되지 않습니다. 모델 자격 증명은 vault에 들어가 컨테이너 트래픽에 주입됩니다. 인바운드 Telegram 메시지는 공급자를 확인하기 전에 라우터와 세션의 인바운드 데이터베이스에 도달하며, 공급자 확인은 컨테이너가 생성될 때 이루어집니다. 따라서 다른 엔드포인트, 키 또는 게이트웨이로는 중단된 폴링 루프, 오래된 서버 측 업데이트 필터, 폴러 충돌, Group Privacy 또는 고장 난 IPv6 경로를 복구할 수 없습니다. 실제로 반대 방향의 연결은 하나 있습니다. NanoClaw README는 /debug 및 모든 /add-channel 스킬의 요구 사항으로 Claude Code를 명시하므로, 에이전트가 다른 곳에서 실행되는 설치에서도 채널을 복구하려면 호스트에 Claude Code가 필요합니다.
봇이 개인 메시지에는 답하지만 그룹을 무시합니다. 이유가 무엇인가요?
이는 보통 NanoClaw의 결함이 아니라 Telegram의 Group Privacy 설정 때문입니다. NanoClaw의 add-telegram 스킬은 Group Privacy가 켜져 있으면 봇이 주소가 지정된 명령과 답장만 보고 일반 텍스트는 보지 못한다고 설명합니다. BotFather에서 /mybots, 봇, Bot Settings, Group Privacy로 이동해 끈 다음 변경 사항이 적용되도록 봇을 그룹에서 제거하고 다시 추가하세요. 비슷해 보이지만 별개의 경우도 있습니다. NanoClaw 이슈 #2989는 더 좁은 allowed_updates 필터로 이전에 폴링된 봇 토큰이 해당 필터를 서버에 영구적으로 유지하여 채널 게시물은 자동으로 누락되고 개인 메시지와 그룹은 계속 작동하는 현상을 보고합니다.
페어링이 절대 완료되지 않지만 봇은 계속 작동합니다. 무엇이 문제인가요?
NanoClaw 이슈 #3162가 바로 이 형태를 설명합니다. 채널 시작 시 getMe 호출이 한 번 실패하면 봇 사용자 이름이 전체 프로세스 수명 동안 null로 캐시되고, 보내는 모든 페어링 코드가 일반 메시지로 처리되며 시도 기록이 남지 않아 설치 프로그램이 영원히 대기합니다. 유일한 흔적은 페어링을 시도하기 몇 분 전 부팅 시 기록되는 경고 한 줄이며, 이슈에 따르면 다른 변경 없이 재시작하면 해결됩니다. 현재 channels 브랜치의 어댑터도 재시도 없이 해당 조회를 한 번 수행하고 결과를 캐시합니다. 또한 NanoClaw 문서는 최대 5개의 재생성 코드를 실행당 사용할 수 있는 일회성 6자리 코드를 설명하지만, 이슈 #3162는 이를 4자리 코드라고 부릅니다. 문서를 따르세요.
2026년 9월 21일 확인: nanocoai/nanoclaw 저장소 기록과 릴리스 목록, 이슈 #2377, #2989, #3162, #3569 및 #3728과 풀 리퀘스트 #2225, #2697, #3449, #3460 및 #3570의 열린/종료 상태, channels 브랜치의 Telegram 어댑터 소스, npm의 고정된 4.29.0 어댑터 빌드와 현재 4.41.0 어댑터 빌드, NanoClaw의 채널·자격 증명·문제 해결·어댑터 인터페이스 문서, add-telegram 및 debug 스킬, Telegram의 Bot API 페이지를 확인했습니다. 이 페이지의 어떤 내용도 실행 중인 NanoClaw 설치 환경에서 실행하지 않았습니다. Kunavo 토큰 요금은 현재 카탈로그에서 가져왔으며, 달러 수치는 예시적인 토큰 산술입니다.