DAO-Code не открывается в macOS? Руководство по исправлению разрешений и PATH (2026)

dao не найден, macOS показывает «неизвестный разработчик», а запуск из каталога заканчивается EACCES или ошибкой авторизации.

Самый быстрый путь — не переустанавливать DAO-Code, а сохранить исходную ошибку, проверить which, путь к файлу и версии, затем последовательно исправить PATH, права выполнения, Gatekeeper, npm EACCES и API Key. На этой неделе сначала создайте диагностический файл без секретов, а уже потом меняйте настройки.

Эта статья для вас, если после установки DAO-Code команда сообщает command not found, macOS блокирует бинарный файл, npm возвращает ошибку доступа или программа запускается, но не проходит проверку API Key. Если вы ещё не устанавливали инструмент, начните с официальной инструкции DAO-Code для macOS, а не с этого материала.

Карта симптомов и точка входа

Одна и та же фраза «DAO-Code не открывается в macOS» может описывать разные уровни сбоя. Если оболочка не видит команду, до проверки API или модели дело ещё не дошло. Если появляется окно безопасности, это уже не проблема PATH. Если команда запускается и только затем возвращает ошибку доступа к модели, повторная установка бинарного файла не поможет.

Сначала сохраните:

• полный текст ошибки из терминала;
• способ установки — официальный скрипт, npm или ручная загрузка;
• результат uname -m;
• результат which dao;
• вывод node --version и npm --version;
• каталог, из которого вы запускаете команду.

Не публикуйте содержимое .env, токен, имя пользователя macOS и полный домашний путь. Для обращения в поддержку замените секреты и личные каталоги на <API_KEY>, <USER> и <PROJECT>.

В качестве первого решения выбирайте ветку по симптомам:

• Если which dao ничего не выводит, но файл существует, исправляйте PATH. Если файла нет, переходите к проверке официального способа установки.
• Если полный путь запускается, а короткая команда нет, проблема почти наверняка в PATH или в конфигурации оболочки.
• Если macOS показывает блокировку, сначала подтвердите источник и подпись файла. Только после этого рассматривайте точечное разрешение.
• Если есть EACCES при установке, используйте пользовательский каталог или менеджер версий Node.js. sudo оставьте вне стандартного сценария.
• Если команда запускается и падает на API, не меняйте права на бинарный файл: проверяйте ключ, аккаунт и актуальность интерфейса модели.

PATH и отсутствующий исполняемый файл

Для начала выполните команды в новом окне Terminal:

uname -m
which dao
command -v dao
type -a dao
node --version
npm --version

which и command -v показывают, видит ли текущая оболочка команду. type -a дополнительно помогает обнаружить несколько установок с одинаковым именем. Это важно после перехода между системным Node.js, менеджером версий и npm-глобальной установкой.

Затем проверьте типичные каталоги, не подставляя путь наугад:

ls -la /usr/local/bin/dao
ls -la /opt/homebrew/bin/dao
npm prefix -g
npm bin -g

Некоторые команды могут вернуть No such file or directory. Это не самостоятельная ошибка DAO-Code — такой результат означает, что конкретный каталог не содержит файл. Посмотрите значение глобального префикса и проверьте каталог, который действительно вернул npm.

Если файл найден, временно запустите его полным путём:

/полный/путь/к/dao --version

Временный запуск доказывает только наличие исполняемого файла. Он не исправляет PATH. Для постоянной настройки сначала определите используемую оболочку:

echo "$SHELL"
ps -p $$ -o command=

Для zsh обычно читается ~/.zshrc, но не добавляйте строку, пока не знаете каталог. Пример безопасного добавления для конкретного пути:

echo 'export PATH="/проверенный/каталог:$PATH"' >> ~/.zshrc
source ~/.zshrc
command -v dao
dao --version

После этого полностью закройте Terminal, откройте новое окно и повторите command -v dao. Проверка в новом процессе обязательна: source обновляет только текущую сессию. Если новая сессия снова не видит команду, проверьте, не запускается ли оболочка с другим конфигурационным файлом.

Официальный установочный скрипт DAO-Code описывает каталог размещения и обработку установочных атрибутов; сверяйте фактический путь с текстом install.sh DAO-Code. Не заменяйте официальный путь произвольным каталогом из чужой инструкции.

Права файла и защита macOS

permission denied у найденного файла — это отдельная проблема. Сначала посмотрите права:

ls -l /полный/путь/к/dao
file /полный/путь/к/dao

Если у владельца нет бита выполнения, добавьте его только для этого файла:

chmod u+x /полный/путь/к/dao
/полный/путь/к/dao --version

Не используйте рекурсивный chmod -R 777. Он меняет права у всех объектов каталога и скрывает, какой именно файл был неисправен. Для запуска достаточно точечного изменения исполняемого файла.

Следующая проверка — атрибут карантина:

xattr -l /полный/путь/к/dao

Если вывод содержит com.apple.quarantine, сначала проверьте, откуда получен файл, совпадает ли его контрольная сумма с опубликованной, и соответствует ли он вашей архитектуре. Gatekeeper предназначен для проверки источника и запуска приложений; описание Gatekeeper и защиты выполнения от Apple объясняет, почему системную защиту нельзя считать обычным препятствием.

Важно: не удаляйте карантинный атрибут у файла неизвестного происхождения. Если источник нельзя подтвердить, безопаснее удалить бинарный файл и повторить установку из официального репозитория, чем превращать предупреждение macOS в разрешение без проверки.

Если источник подтверждён, а macOS всё равно показывает предупреждение, используйте точечный сценарий, а не глобальное отключение защиты. Официальные действия для приложения неизвестного разработчика описаны в инструкции Apple по открытию проверенного приложения. После разрешения снова выполните:

dao --version

Если версия выводится, но запуск проекта блокируется, проверьте уже не бинарный файл, а каталог проекта и его права. Не смешивайте эти два уровня.

npm EACCES и несовместимый Node.js

Ошибка npm ERR! code EACCES означает, что npm не может записать в выбранный каталог. Частая ошибка — немедленно повторить ту же команду с sudo. Это может создать файлы, принадлежащие root, после чего обычный пользователь получит новые конфликты.

Сначала соберите контекст:

npm config get prefix
npm root -g
ls -ld "$(npm config get prefix)"
node --version
npm --version

Затем сравните установленную версию Node.js с ограничениями в package.json DAO-Code. Не угадывайте требование по чужому посту: оно может измениться вместе с проектом. Если версия не подходит, замените Node.js через менеджер версий или настройте пользовательский prefix. Официальная последовательность для ошибки глобальных разрешений приведена в документации npm по EACCES.

Пользовательский prefix выглядит так:

mkdir -p "$HOME/.npm-global"
npm config set prefix "$HOME/.npm-global"
echo 'export PATH="$HOME/.npm-global/bin:$PATH"' >> ~/.zshrc
source ~/.zshrc
npm config get prefix
command -v dao

Если вы уже запускали npm с sudo, проверьте владельца каталога, но не меняйте владельца всей домашней директории:

ls -ld "$(npm root -g)"
ls -la "$(npm root -g)"

Исправляйте только каталог, который принадлежит установке DAO-Code и действительно требует доступа. Сохраните вывод до изменения, чтобы можно было откатить решение.

Архитектура Apple Silicon и Intel

Ошибка bad CPU type in executable относится к архитектуре, а не к разрешениям. Выполните:

uname -m
file /полный/путь/к/dao

На Apple Silicon система обычно сообщает arm64, а бинарный файл должен содержать совместимую архитектуру или поддерживаемый универсальный вариант. На Intel Mac результат x86_64. Сравните эти значения с активом, который установочный скрипт выбрал для вашей системы. Официальное описание установки и быстрых команд находится в README DAO-Code.

Не скачивайте бинарный файл для другой архитектуры только потому, что его имя похоже. Удалите неправильный файл, повторите установку официальным способом и снова проверьте file. Если вы работаете через терминал, запущенный в другом режиме совместимости, дополнительно сравните:

arch
uname -m

Если uname -m и ожидаемая архитектура проекта расходятся, сначала исправьте среду запуска. Не смешивайте в одном PATH arm64- и x86_64-версии без ясной причины: command -v dao может указывать не на тот файл, который вы только что проверили.

Установка завершилась, но команда всё ещё отсутствует — что делать?

Сначала откройте новый терминал и выполните command -v dao. Если результата нет, проверьте npm prefix -g, содержимое соответствующего bin и файл ~/.zshrc. Если полный путь работает, переустановка не требуется. Если самого файла нет, только тогда повторяйте установку после проверки архитектуры и версии Node.js.

API Key после успешного запуска

Успешный вывод версии не означает, что модельный запрос будет принят. Здесь важно разделить два события:

1. локальная команда DAO-Code запустилась;
2. удалённый API подтвердил ключ и разрешил запрос.

Проверьте, где проект ожидает ключ: переменная окружения, файл конфигурации или настройка профиля. Сверьте название переменной с разделом конфигурации в официальном quick start DAO-Code. Не переносите имя переменной из старой инструкции без проверки.

Диагностический порядок:

printenv | grep -E 'API|KEY|TOKEN'
pwd
ls -la

Последняя команда показывает только имена файлов и права, но printenv может раскрыть секрет, если вывести значение целиком. Используйте его лишь локально и не вставляйте результат в отчёт. Безопаснее проверить наличие переменной условно:

if [ -n "$DAO_CODE_API_KEY" ]; then
  echo "Ключ задан"
else
  echo "Ключ не задан"
fi

Замените имя переменной на то, которое указано в актуальной конфигурации DAO-Code. Если ключ задан, но авторизация не проходит, проверьте состояние аккаунта, права токена, лимиты и изменения официального API. Ошибка сети, отказ аккаунта, неверное имя модели и пустой ключ выглядят похоже только на верхнем уровне. Mac не является доказанной причиной, пока журнал не показывает локальную ошибку.

Как сбросить неработающий API Key?

Удалите ключ из места, где он действительно хранится, затем создайте новый в официальном кабинете соответствующего API и задайте его заново в ожидаемом формате. Не вставляйте секрет в команду, shell history, снимок экрана или тикет. После изменения закройте текущую сессию Terminal, откройте новую и выполните контролируемый запрос без вывода заголовков авторизации.

Приёмка после исправления

Исправление считается завершённым не после исчезновения одного сообщения, а после повторяемой проверки. Выполните пункты по порядку:

• [ ] Сохранён исходный текст ошибки без секретов.
• [ ] Зафиксированы uname -m, node --version, npm --version.
• [ ] command -v dao показывает ожидаемый путь.
• [ ] file подтверждает подходящую архитектуру.
• [ ] ls -l показывает право выполнения только у нужного файла.
• [ ] PATH работает в новом окне Terminal, а не только после source.
• [ ] Установочный каталог не требует sudo для обычного запуска.
• [ ] Карантин удалён только после проверки источника либо обработан через штатное предупреждение macOS.
• [ ] Версия DAO-Code выводится без обращения к проектному секрету.
• [ ] Тестовый запрос проходит с ключом, который не отображается в журнале.
• [ ] После перезагрузки или нового входа настройки сохраняются.
• [ ] Рабочий каталог содержит только ожидаемые изменения.

Если после этого ошибка повторяется, соберите шаблон:

macOS:
Архитектура:
Способ установки:
Команда:
Полный текст ошибки:
Результат command -v dao:
Результат dao --version:
Версия Node.js:
Изменения PATH:
Проверка API без секрета:

Для сложных случаев полезно начать с чистой среды, но сначала сохраните этот шаблон и исходную ошибку. Если над одним проектом работают несколько человек, ручная история прав, старые Node.js и остаточные npm-каталоги мешают повторяемости. В такой ситуации можно оценить условия удалённой Mac-среды как отдельную площадку для чистой проверки.

Локальный Mac лучше, когда вам нужны физические устройства, постоянный доступ без аренды и длительная стабильная нагрузка. Но при срочном восстановлении DAO-Code он может проигрывать из-за старого PATH, смешанных архитектур, root-файлов после sudo и накопленных разрешений Gatekeeper. Удалённая среда Hashvps даёт другой сценарий: вы начинаете с заранее согласованной конфигурации, можете отделить эксперимент от личного компьютера и после проверки быстрее повторить окружение для команды. Это разумный вариант для временного тестирования, разбора ошибки или восстановления разработки, но не обязательная замена вашему Mac для постоянных тяжёлых задач и работы с физическими интерфейсами.

Главное — не начинать с отключения защиты и повторной установки. Сначала зафиксируйте симптом, найдите реальный файл, подтвердите архитектуру, исправьте только нужный слой и проведите проверку в новом процессе.