Claude Code — это не вкладка в браузере, которую можно закрыть и забыть. Это CLI-инструмент, который читает репозиторий, правит файлы, вызывает другие утилиты, запускает shell-команды и работает в той же среде, где разработчик часто держит токены, git-remotes, тестовые данные и скрипты деплоя. Поэтому история со скрытой проверкой китайских пользователей в Claude Code важна даже в том случае, если слово spyware в этой дискуссии слишком грубое.

Терминальный AI-агент для кода, подключенный к исходникам, shell-командам, прокси, sandbox, журналу аудита и защищенному репозиторию

История началась с reverse-engineering поста на Reddit 30 июня. Автор LegitMichel777 писал, что использовал Claude Code через прокси и начал разбирать CLI после того, как версия 2.1.196 отключила remote-control при custom endpoint. В бинарнике он, по его словам, нашел код, присутствовавший с версии 2.1.91 от 2 апреля. Механизм проверял, включен ли прокси, совпадает ли timezone с Asia/Shanghai или Asia/Urumqi, и похож ли proxy URL на китайский домен или адрес AI-лаборатории.

Спорным оказался не сам факт проверки локальных и сетевых признаков. Облачные сервисы давно смотрят на похожие сигналы. Спорным был способ передачи результата. Reddit-пост и The Decoder описывали мелкие изменения в system prompt, который отправляется Anthropic: формат даты и символ, похожий на апостроф, во фразе "Today's date is". По версии автора, человек почти не видит разницы, но сервер может ее распарсить. The Decoder также писал об XOR-обфускации с ключом 91 и отсутствии упоминания в release notes.

Ответ Anthropic быстро перевел историю из режима громкого обвинения в более сложную зону доверия. Инженер команды Claude Code Thariq Shihipar написал в X, что это был эксперимент, запущенный в марте, чтобы бороться с abuse со стороны неавторизованных реселлеров и защищаться от distillation. Он добавил, что команда уже внедрила более сильные меры и давно собиралась убрать эксперимент; pull request на rollback уже был merged. Это важная деталь: речь не обязательно о втором секретном канале утечки кода. Но остается вопрос: что поставщик обязан раскрывать, если привилегированный локальный агент использует скрытые маркеры для anti-abuse политики?

Что подтверждено, а что пока лучше формулировать осторожно

Надежно известно, что Reddit-пост существует и содержит подробную техническую претензию по версиям Claude Code, proxy-check, timezone-check и hidden prompt markers. Обсуждение было активным: сотни комментариев, заметный раскол между теми, кто видит нарушение доверия, и теми, кто считает это нормальной anti-abuse мерой против прокси, реселлеров и model distillation. The Decoder и TNW подробно пересказали механизм. Slashdot подхватил Reuters-линию про Alibaba, что вывело тему за пределы AI-сообществ.

Некоторые детали нужно не разгонять сильнее источников. TNW и Slashdot пишут, что Alibaba запретит Claude Code в рабочих окружениях с 10 июля, ссылаясь на Reuters и источник, знакомый с ситуацией. В этих материалах нет полного публичного технического advisory от Alibaba. Поэтому корректно писать "по сообщениям" или "по данным Reuters-linked reports", а не "Alibaba доказала backdoor". Слово backdoor тоже лучше использовать как цитируемое обвинение, а не как собственный технический вывод статьи.

Еще один нюанс: механизм, судя по обсуждениям и GitHub issues, связан с proxy/custom endpoint, особенно с ANTHROPIC_BASE_URL. Это не делает тему неважной. Многие power users, корпоративные gateways, cost-control proxies и multi-model wrappers используют custom endpoints. Но степень риска для обычного пользователя, который ходит напрямую в стандартный API Anthropic, будет другой. Практический вывод не в том, что Claude Code тайно отправлял все репозитории. Вывод в том, что coding agent стал supply-chain компонентом: обновляемым бинарником с сетью, локальным контекстом и поведением, которым управляет поставщик.

Почему Anthropic могла это сделать

У Anthropic есть понятные причины бороться с реселлерами, региональными обходами и distillation. Frontier-модели дороги в обслуживании. Их ответы могут использоваться для обучения конкурирующих моделей. Если доступ массово перепродают через прокси или фермы аккаунтов, поставщик будет искать признаки такого использования.

Сам мотив не выглядит абсурдным. Fraud systems, платежные сервисы и SaaS-платформы постоянно используют timezone, endpoint, домены, IP и другие metadata. Проблема в другом: Claude Code — не страница оплаты. Он работает внутри среды разработки. Он видит файлы, команды, историю git, локальные конфиги и иногда секреты. Скрытый prompt marker в таком инструменте воспринимается иначе, чем явная проверка риска на веб-сайте.

Почему пользователи возмутились

Главная претензия не в наличии anti-abuse. Главная претензия в скрытности, обфускации и отсутствии в release notes. Если цель легитимна, почему механизм был невидимым для пользователя? Почему результат кодировался в prompt path, а не в понятном telemetry field? Security-команды часто мирятся с неприятными контролями, если они описаны и управляемы. Хуже, когда контроль выглядит намеренно спрятанным.

Вторая претензия — права инструмента. Браузер и terminal coding agent находятся в разных threat model. Один Reddit-комментатор сформулировал это жестко: браузерам обычно не дают root. Даже без root CLI-agent может видеть working tree, package scripts, environment variables, внутренние документации и имена приватных сервисов. Если поставщик меняет способ кодирования локальных сигналов в таком инструменте, компании хотят знать об этом заранее.

Третья проблема — сама идея скрытого сигнала в system prompt. Обычное telemetry field можно задокументировать, отключить, залогировать или пропустить через enterprise policy. Невидимая вариация внутри prompt сложнее для аудита и объяснения. Инженерно это может быть clever. Для доверия это не всегда плюс.

Почему часть сообщества считает историю преувеличенной

И противоположная позиция тоже имеет смысл. Многие комментаторы писали, что находка не доказывает тайную отправку исходного кода или отдельный шпионский канал. Маркер, судя по описанию, шел через обычный request path. Входными данными были proxy и timezone signals, а не содержимое приватного репозитория. Если пользователь использовал custom endpoint или прокси, похожий на resale-сценарий, детектор со стороны поставщика не выглядит шокирующим.

Есть и policy-контекст. Anthropic не предоставляет Claude во всех регионах и публично говорит о рисках model distillation. Компания под таким давлением не будет считать каждый запрос невинным. С этой точки зрения провал может быть не в наличии детектора, а в коммуникации продукта.

Поэтому полезный вывод не "Claude Code безопасен" и не "Claude Code malware". Полезный вывод: agentic developer tools дошли до уровня, где telemetry, anti-abuse, update channels и local permissions нужно обсуждать явно. Иначе любой скрытый контроль превращается в кризис доверия.

Alibaba — сигнал для enterprise

История с Alibaba важна не только сама по себе. По Reuters-linked материалам, пересказанным TNW и Slashdot, Alibaba собирается запретить Claude Code в рабочих окружениях с 10 июля и рекомендовать собственный Qoder. Мотивы могут быть смешанными: безопасность, конкуренция, политика, PR. Но итог понятен: AI coding tools попадают в allowlist и denylist.

Компании теперь спрашивают не только "хорошо ли агент пишет код". Они спрашивают, кто управляет инструментом, куда уходят запросы, что он может читать, что может запускать, как обновляется, какие endpoints использует, что происходит при flagging пользователя или прокси, и как быстро инструмент можно отключить после потери доверия.

В 2026 году AI coding agents становятся частью software supply chain. Это одновременно npm-пакет или бинарник, облачный сервис, локальная автоматизация и policy surface. Их стоит контролировать так же скучно, как package managers, CI runners, browser extensions и deployment bots.

Чек-лист для компаний

Первое правило: не относиться к coding agent как к безобидному чату. Если инструмент читает код и запускает команды, он должен работать в контролируемой среде. Контейнер, VM или sandbox на репозиторий — нормальная базовая практика. Агент не должен автоматически наследовать весь home directory разработчика, личные SSH keys, production kubeconfig, cloud admin tokens и password-manager exports.

Ограничьте доступ к файлам. Дайте агенту нужный репозиторий, а не всю машину. Уберите .env, customer data, production dumps и долгоживущие credentials из доступной области. Если агенту нужен токен, сделайте узкий токен под конкретную задачу и ротируйте его.

Контролируйте сеть. Решите, может ли инструмент ходить напрямую к vendor API, через внутренний gateway, через proxy или только из конкретной egress-сети. Логируйте outbound domains. Фиксируйте, какая версия инструмента делала какие классы запросов. Если используется ANTHROPIC_BASE_URL или аналогичная настройка, это должен быть документированный элемент архитектуры, а не случайная переменная в shell history.

Пиньте версии, где возможно. Быстро развивающиеся agents меняют поведение быстрее, чем корпоративный review успевает реагировать. Auto-update удобен для личного эксперимента, но опасен для инструмента, который трогает source code и secrets. Новые версии стоит прогонять в staging, читать changelog и иметь rollback.

Оставьте ручные approvals для опасных действий. Агент может предлагать shell commands, но не должен сам выполнять разрушительные операции по умолчанию. Разделяйте read-only exploration и writes. Всегда смотрите git diff, test output и список измененных файлов перед commit. Не включайте SSH agent forwarding без конкретной причины. Не давайте sudo и production deploy доступ потому, что демо выглядело убедительно.

Ведите аудит. Terminal logs, tmux history, tool-call records и diff — это не бюрократия. Это единственный способ понять, что агент сделал за длинную сессию. Если AI-инструмент меняет код, commit и review должны оставлять след: что менялось, кем проверено, какую роль играл агент.

Что делать individual developers

Личная версия проще. Запускайте coding agents в отдельном user account, container или disposable checkout, когда это возможно. Не стартуйте их из каталога, где лежит вся ваша жизнь. Не держите cloud tokens и private keys рядом с working tree. Проверяйте diff before commit. Используйте отдельный API key для экспериментов. Если используете proxy или third-party gateway, считайте, что и vendor, и gateway могут видеть достаточно metadata, чтобы классифицировать трафик.

Для чувствительной работы часто лучше старый скучный процесс: агент помогает думать, искать, писать черновик патча и запускать тесты в ограниченном repo; production credentials и deployment остаются вне агента; patch review проходит так, будто код принес очень быстрый junior contractor. Это не звучит футуристично, зато работает.

Какие вопросы теперь задавать vendor'ам

История Claude Code дает нормальный questionnaire для закупки и security review. Какие metadata собирает CLI? Как выбираются локальные файлы для context? Может ли prompt содержать скрытые vendor markers? Как отключается telemetry в enterprise? Какие endpoints доступны инструменту? Используются ли prompts or code snippets для training? Как документируются security-relevant changes?

Спросите про updates. Можно ли pin version? Можно ли mirror package? Есть ли detailed release notes? Есть ли restricted-network или no-network mode? Изолированы ли MCP servers and plugins? Есть ли audit log для tool calls, file writes and shell execution? Что происходит, если vendor помечает proxy, region, endpoint или account как risky?

Open source agent не становится безопасным автоматически. Он тоже может утечь через model API, plugin, dependency или careless shell command. Но открытый код и reproducible builds облегчают аудит. Закрытый инструмент тоже может быть приемлемым, если дает прозрачность и controls. Вопрос не в идеологии, а в ограничении ущерба.

Вывод

История Claude Code может оказаться не катастрофической утечкой, а неудачно спрятанным anti-abuse экспериментом. Но она уже показала правильную проблему: AI coding agents слишком полезны, чтобы их игнорировать, и слишком привилегированы, чтобы доверять им на репутации бренда.

Хорошая политика не обязана запрещать всех агентов. Она должна считать их участниками software supply chain. Узкий доступ, сетевой контроль, pinned versions, audit logs, review patches, documented vendor controls. Тогда продуктивность остается, а ущерб от неожиданного поведения ограничен.

Как только AI-agent оказывается внутри терминала, доверие перестает быть ощущением. Оно становится инженерной настройкой.