Разбор Claude Desktop: MCP-сервер работает вне песочницы

Автор блога Telkins разобрал сборку 1.40609.1 приложения Claude для macOS и выяснил, где на самом деле исполняется то, что делает агент Cowork. Shell-команды и сгенерированный код уходят в отдельную Linux-машину. Локальный MCP-сервер при этом запускается обычным процессом на самом Mac, вне всякой виртуализации.

В разборе Telkins, опубликованном 8 сентября, бандл весит 855 МБ, и около 60% из них занимают Electron и ресурсы Chromium. Нативная часть лежит в бинарниках .node, которые линкуются с фреймворками Apple, веб-интерфейс собран в ion-dist/, а рядом лежат образы smol-bin, о которых ниже.

Как поднимается гость

Swift-аддон линкуется с Apple Virtualization.framework и управляет виртуальной машиной. Саму гостевую систему приложение скачивает при запуске. Автор взял arm64-образ ревизии, опубликованной 13 августа: в манифесте четыре артефакта, это корневой диск rootfs.img, ядро vmlinuz, обычный initrd и облегчённый initrd-micro для быстрой загрузки. Диск весит 1,23 ГБ в сжатом виде и разворачивается ровно в 10 ГиБ. Внутри Ubuntu 22.04.5 LTS с ядром 6.8.0-136-generic, Node.js 22.23.2, Python 3.10.12 и uv.

Главный жилец образа - /usr/local/bin/sdk-daemon, стрипнутый Go-бинарник, собранный Go 1.25.12. Юнит coworkd.service запускает его от root. Ещё там лежит набор для работы с документами: pdfplumber, camelot для таблиц из PDF, pytesseract для OCR, headless LibreOffice через unoserver, markitdown, magika для определения типа файла и скрипт extract-text, который раздаёт форматы между MarkItDown, Pandoc и LibreOffice.

Цепочка запуска такая: Electron просит нативный слой загрузить гостя, coworkd поднимает демон, и дальше Swift-класс CoworkVMRPCClient обменивается с ним JSON-сообщениями по vsock. Vsock - это сокет между хостом и гостем, которому не нужна сеть. По нему же демон отправляет на хост трафик виртуального Ethernet-интерфейса гостя. В метаданных Swift на хосте нашлось имя VZGvisorNetworking, и автор делает вывод, что наружу гостя, судя по всему, выпускает сетевой стек на базе gVisor, работающий на Mac.

Зачем в бандле smol-bin

Образы smol-bin весят всего 24 МБ, по копии на arm64 и x64, потому что приложение универсальное. Автор сначала принял их за загрузочную систему, но это скорее том с готовыми бинарниками и конфигурацией. Хост подключает его к машине вторым виртуальным диском, апдейтер coworkd монтирует его и копирует свежий демон поверх того, что лежит в базовом образе. Хэши двух копий демона у автора не совпали.

Вероятная причина, по версии автора, в протоколе: хост и гость должны одинаково понимать имена и типы полей JSON. Демон, который едет вместе с приложением, Anthropic может обновлять синхронно с клиентом, не заставляя качать заново гигабайтный образ, а тот кэшируется отдельно по версионированному пути и контрольным суммам из манифеста.

Сеть и прокси

Сетевую политику задаёт srt-settings.json из smol-bin. В списке разрешённых доменов реестры npm, yarn, PyPI и crates.io, github.com, архивы Ubuntu и домены Anthropic. Запросы к anthropic.com, claude.com и frame.claudeusercontent.com дополнительно идут через MITM-прокси на сокете /var/run/mitm-proxy.sock. На файловую систему ограничений почти нет: allowWrite равен ["/"], закрыто чтение только /run/systemd/resolve и /run/dbus.

Прокси появился после утечки, которую Anthropic описала сама: вредоносный файл заставил Claude загрузить файлы рабочей папки в аккаунт атакующего через API самой Anthropic. Домен был в списке разрешённых, и запрос прошёл. Теперь прокси внутри машины проверяет запросы к API и требует сессионный токен, выданный этой машине, а ключ атакующего отклоняет. Урок для компании не первый: как пишет The Agent Report, в майском посте Anthropic о сдерживании Claude признавалось, что в claude.ai самым слабым слоем оказался собственный прокси компании, а не gVisor или seccomp.

Что видно в бинарниках

В swift_addon.node остались 28 строк с путями к исходникам, включая каталог сборки /Users/runner/work/apps/apps/packages/desktop/claude-swift/: отдельные папки для диктовки и управления VM, файлы для быстрого ввода и меню в трее. Из метаданных Swift автор восстановил 273 дескриптора полей, имена удалось получить для 175. В computer_use.node перечисления AXDispatch различают исходы ineffective и unsupported и называют причины отказа вроде secureField или windowNotReachable. А структура SpawnProcessArgs передаёт вместе с командой рабочую директорию, переменные окружения, дополнительные монтирования и список разрешённых доменов.

Где кончается песочница

Чтобы проверить, где живёт локальный MCP-сервер, автор добавил в конфигурацию крошечный сервер на Python, инструмент которого сообщал ОС и PID процесса и читал тестовый файл. Ответ пришёл такой: Darwin, PID 18717. В таблице процессов macOS этот процесс висел под Claude: Claude (18616), затем Contents/Helpers/disclaimer (18716), затем сам сервер. Он вернул случайное значение из файла в /private/tmp, который в виртуальную машину никто не отдавал, и ничего для этого обходить не пришлось. Локальный MCP-сервер читает всё, что разрешают его настройки и права macOS.

Внутри машины тоже есть оговорка. Папки хоста, подключённые на запись, агент может менять и удалять, и остановка процесса этих изменений не откатит.

Координацию Anthropic тоже вынесла на Mac: приложение общается с моделью, раздаёт вызовы инструментов и собирает результаты. Раньше это работало внутри VM, но неудачный старт машины оставлял Claude без возможности ответить. Сейчас, как сказано в справке Anthropic, при недоступной VM файловые и веб-инструменты продолжают работать, а shell и выполнение кода отвечают «workspace unavailable». Защита машины распространяется только на то, что запущено внутри неё.

Там же сказано, что сессии Cowork теперь по умолчанию идут в облаке, на серверах Anthropic, и локальные MCP-серверы в них не запускаются. Локальное исполнение, на котором проводился этот разбор, осталось для уже существующих десктопных развёртываний.