Mac постоянно запрашивает разрешение на запись экрана: рабочие решения

Вы открываете Zoom, нажимаете Share Screen — и macOS показывает ровно тот же диалог, что и месяц назад: можно ли Zoom записывать ваш экран. Вы уже отвечали «да». Вы заходите в System Settings, и вот оно: Zoom в списке Screen & System Audio Recording, переключатель включён. Ничего не сломано. И тем не менее вас спросили снова.

Через неделю происходит кое-что другое. Ваша программа резервного копирования не может прочитать папку Mail. Вы проверяете Full Disk Access — приложение в списке, переключатель включён, ровно так, как и должно быть. Но приложение ведёт себя так, будто разрешения у него нет вообще. Это не та же самая проблема, хотя ощущение она вызывает точно такое же.

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

В этой статье мы разделяем эти два случая, объясняем подсистему, лежащую в основе обоих, и даём правильное решение для каждого. Здесь же объясняется, почему самый распространённый совет по этой теме — поменять права доступа к файлам через chmod или запустить какое-нибудь «восстановление прав» — не имеет ни малейшего отношения к задействованной системе. Всё, что показано ниже, проверено на Mac под управлением macOS 26.5.2, сборка 25F84, с включённой System Integrity Protection.

Ключевые выводы

• Две разные проблемы носят одну маску — запланированный повторный запрос для захвата экрана предусмотрен разработчиками и отключить его нельзя, а выданное, но неработающее разрешение — это реальная неисправность с реальной причиной.
• TCC привязывает разрешение к идентичности подписи кода приложения, а не к его пути — именно поэтому разрешение молча перестаёт работать после обновления, перемещения или когда на диске оказываются две копии одного приложения.
• tccutil reset — единственная команда, которую поставляет Apple — выдать разрешение из Terminal невозможно, а запуск reset без идентификатора бандла стирает это разрешение для всех приложений на Mac.
• Базы данных приватности недоступны даже для ls — на тестовом Mac с включённой SIP попытка вывести содержимое любого из каталогов TCC возвращает Operation not permitted, и это самое наглядное доказательство того, что речь идёт не об обычных правах доступа к файлам.
• Apple не публикует список имён служб — названия вроде ScreenCapture и SystemPolicyAllFiles — это знание сообщества, и любое руководство, выдающее их за официальную документацию, просто угадывает.

Что такое TCC и чем оно не является

Подсистема, которая решает, может ли приложение записывать ваш экран, читать папку Mail, использовать микрофон или управлять другими программами, называется TCC. Аббревиатура расшифровывается как Transparency, Consent and Control — прозрачность, согласие и контроль. Именно она выводит каждое окно «App would like to access…», через которое вы когда-либо прокликивали, и именно она наполняет каждый список в System Settings в разделе Privacy & Security.

Страница man от Apple для единственной утилиты командной строки в этой области описывает её одним предложением. В разделе NAME сказано «tccutil – manage the privacy database», а DESCRIPTION разворачивает это так: «The tccutil command manages the privacy database, which stores decisions the user has made about whether apps may access personal data».

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

База данных приватности — это не файловая система

Именно это заблуждение отнимает больше времени, чем любое другое, поэтому от него стоит избавиться сразу.

Традиционные права доступа Unix — это атрибуты, хранящиеся на самом файле: владелец, группа и биты чтения/записи/выполнения, меняющиеся командами chmod и chown. Они отвечают на вопрос «какие учётные записи могут трогать этот файл?»

TCC отвечает на совершенно другой вопрос: «какому приложению пользователь согласился разрешить чтение этой категории данных?» Субъектом здесь является не учётная запись. Субъект — приложение. Ховард Оукли из The Eclectic Light Company хорошо сформулировал это различие в своём ноябрьском разборе 2025 года о правах и приватности, написав, что «privacy protection operates outside of file attributes, using a rule-based system applied to each app».

Практическое следствие абсолютно. Ваша учётная запись уже владеет ~/Library/Mail, и биты POSIX уже говорят, что вы можете это читать. Именно поэтому команда в терминале, запущенная от вашего имени, может это прочитать, а GUI-приложение, запущенное от вашего же имени, — нет: права доступа к файлам никогда не были препятствием. Препятствием был TCC.

Так что никакое количество chmod не исправит проблему TCC. Как не исправит её и никакая процедура «восстановления прав» — концепция родом из эпохи до APFS, применявшаяся к базе данных квитанций и удалённая Apple из Disk Utility много лет назад. Запуск sudo chmod -R 755 по всей домашней папке в погоне за диалогом о записи экрана не поможет и может повредить вашу папку Library. Не делайте так.

Базы данных, которые нельзя прочитать — их даже нельзя перечислить

Баз данных TCC две. Пользовательская лежит в ~/Library/Application Support/com.apple.TCC/ и хранит решения, действующие для вашей учётной записи. Общесистемная лежит в /Library/Application Support/com.apple.TCC/ и хранит решения, действующие для всей машины, включая те, что может задать администратор или профиль MDM.

Вот демонстрация, которая закрывает спор. На тестовом Mac с включённой SIP были выполнены обе команды:

ls ~/Library/Application\ Support/com.apple.TCC/
ls /Library/Application\ Support/com.apple.TCC/

Обе вернули Operation not permitted. Не «permission denied», как выглядит отказ на уровне POSIX, а именно тот ответ, который ядро даёт, когда System Integrity Protection блокирует доступ полностью. Активность SIP была подтверждена: csrutil status вернула System Integrity Protection status: enabled.

Вы не можете ни перечислить содержимое этих каталогов, ни прочитать лежащие в них базы, ни отредактировать их. Если руководство советует вам открыть TCC.db в браузере SQLite и вставить строку, оно описывает машину с отключённой SIP, а отключение SIP ради обхода запроса разрешений меняет значительную часть защитной архитектуры вашего Mac на решение проблемы с диалоговым окном. Эта статья не будет рассказывать, как это сделать.

Что вы действительно можете сделать: выдать разрешение через интерфейс System Settings, сбросить решение с помощью tccutil или позволить профилю MDM записать решение за вас. Это три двери. Четвёртой нет.

Зачем нужен такой дизайн

Если бы решения TCC хранились в обычном редактируемом файле, любое приложение с правом записи в вашу домашнюю папку могло бы молча выдать себе запись экрана, доступ к камере и полную свободу в папке Mail. Защита была бы бесполезной. Поэтому Apple убрала решения за SIP, сделала единственным поддерживаемым путём записи взаимодействие пользователя с системным диалогом и дала утилите командной строки ровно один глагол: reset.

Это связный дизайн — и, с точки зрения человека, чинящего сломанное разрешение в 11 вечера, очень маленький набор инструментов. Большая часть этой статьи о том, как пользоваться им грамотно. Более широкий контекст того, как macOS сочетает Gatekeeper, нотаризацию, SIP и TCC, разобран в нашем полном руководстве по безопасности и приватности macOS Tahoe, которое охватывает окружающую архитектуру.

Две разные проблемы

Теперь к разделению, на котором держится вся остальная часть статьи.

Проблема первая: намеренный повторный запрос

Во время бета-цикла macOS 15 Sequoia в 2024 году Apple ввела периодическое переподтверждение для захвата экрана и звука. Любое приложение, снимающее ваш экран, должно переподтверждать разрешение по расписанию, и отказаться от этого нельзя.

Изначально в бете это происходило еженедельно, а также после каждого перезапуска. Это вызвало серьёзную публичную критику. MacRumors сообщал в августе 2024 года, что «popups for screen recording app permissions have been showing weekly up throughout the beta testing process, but Apple has tweaked the frequency in response to user feedback» и что бета перешла на ежемесячную переавторизацию. 9to5Mac и iDownloadBlog сообщали о том же изменении в той же бете. Запрос после каждого перезапуска был убран тогда же. Диалог предлагает кнопку «Allow For One Month» и вариант открыть System Settings, и MacRumors тогда отметил, что «it does not appear that there is a way for users to permanently give screen recording access to recording functionality, but a monthly popup is at least more convenient than a weekly popup».

Теперь честная часть. Мне не удалось подтвердить текущую периодичность в поколении macOS 26 ни по одному авторитетному источнику. Собственная страница поддержки Apple для этой панели — «Allow apps to use screen and audio recording» в Mac User Guide для macOS Tahoe 26 — описывает, как открыть панель и как ответить на диалог, и не говорит ровным счётом ничего о периодическом переодобрении. Вторичные источники, обсуждающие macOS 26, противоречат друг другу: одни описывают еженедельный повторный запрос, другие ежемесячный, и ни один не ссылается ни на что.

Итак, вот что можно утверждать уверенно, а что нельзя. Подтверждено: периодический повторный запрос появился в цикле Sequoia, относится к захвату экрана и системного звука, предлагает разрешение на месяц и не имеет пользовательского выключателя. Подтверждено: текущая документация поддержки Apple по этой панели не упоминает его вообще. Не подтверждено: точный интервал в поколении macOS 26. Если ваш Mac переспрашивает примерно раз в месяц, это соответствует тому, что Apple выпустила в Sequoia. Если он спрашивает существенно чаще, читайте диагностику неисправностей ниже, потому что частые повторные запросы — это уже другая проблема.

Самое полезное, что нужно знать о Проблеме первой: это не неисправность, и чинить здесь нечего. Нажать Allow — это одна секунда, и сам диалог и есть переподтверждение, так что переключать что-либо заново в System Settings не нужно. Любое руководство, которое советует сбросить, переустановить или что-то отредактировать в ответ на ежемесячный запрос, продаёт лекарство здоровому пациенту.

Есть одно исключение на стороне разработчика. У Apple есть entitlement с именем com.apple.developer.persistent-content-capture, подавляющий повторяющийся запрос, и блог Майкла Цая собрал обсуждение разработчиков вокруг него в августе 2024 года. Это управляемая возможность, нацеленная на приложения удалённого управления и VNC-подобные программы: разработчики должны подать заявку в Apple и получить одобрение. Как пользователь включить её вы не можете. Она лишь объясняет, почему небольшое число приложений удалённого доступа никогда вас не донимает.

Проблема вторая: разрешение, которое не держится

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

У всего этого есть причины, и у большинства случаев причина одна. Об этом — следующий крупный раздел.

Одна вещь, которой в этом списке нет, хотя кажется, что она туда просится: Mac, постоянно спрашивающий пароль от связки ключей входа. Это подсистема связки ключей, а не TCC, и ничто в этой статье её не исправит. Если это ваш симптом, нужную тему покрывает решение проблемы с запросом пароля связки ключей входа.

Какая проблема у вас

Симптом	Какая проблема	Что делать
Запрос на захват экрана примерно раз в месяц, приложение работает после нажатия Allow	Так задумано	Нажмите Allow. Ничего не сломано.
Запрос при каждом запуске	Неисправность	Проблема с идентичностью подписи или дублирующей копией. См. ниже.
Переключатель в панели включён, приложение всё равно не может выполнить действие	Неисправность	Устаревшая запись, привязанная к старой идентичности. Чистая перевыдача.
Приложение пропало из панели после обновления	Неисправность	Подпись изменилась. Выдайте заново.
Две записи с одинаковым именем в панели	Неисправность	Две копии на диске. Найдите и удалите одну.
CLI-инструмент работает, но никогда не появляется в панели	Известный баг macOS 26.1	См. раздел о командной строке.
Запрос появляется, вы нажимаете Allow, ничего не происходит	Неисправность	Часто приложение не было полностью закрыто. Чистая перевыдача.
Переключатель неактивен, есть примечание о профиле	Управляемый Mac	Обратитесь к тому, кто управляет устройством.
Разрешение не для захвата экрана переспрашивается ежемесячно	Неисправность	Плановый повторный запрос есть только у захвата экрана.

Где находится каждое разрешение в поколении macOS 26

Все эти панели лежат в одном корне. Откройте System Settings, нажмите Privacy & Security в боковой панели, затем выберите категорию. Категории, относящиеся к этой статье:

• Screen & System Audio Recording. Переименована в поколении macOS 26; раньше называлась Screen Recording. Описание Apple умещается в одну строку: «Allow apps to record your screen and audio, or just your audio. The listed apps have access».
• Full Disk Access. Защищённые пользовательские данные по всей системе: Mail, Messages, данные Safari, резервные копии Time Machine и папки контейнеров других приложений.
• Accessibility. Возможность управлять вашим Mac: двигать курсор, кликать, читать содержимое окон, управлять интерфейсами других программ.
• Automation. Право одного конкретного приложения отправлять Apple events другому конкретному приложению. Это единственная панель, устроенная как набор пар, а не плоский список.
• Files and Folders. Точечный доступ к папкам: Desktop, Documents, Downloads, съёмные и сетевые тома. Приложению с Full Disk Access записи здесь не нужны.
• Input Monitoring. Позволяет приложению видеть нажатия клавиш, даже когда оно не на переднем плане.
• Camera и Microphone. Ровно то, что следует из названия. Если проблемы именно у микрофона, у цепочки разрешений на ввод есть свои особенности, разобранные в руководстве по починке микрофона Mac, переставшего работать на macOS Tahoe 26.5.
• Local Network. Более новая панель и частый источник путаницы, потому что заблокированное разрешение на локальную сеть даёт симптомы, совершенно не похожие на проблему приватности. Классический пример — переставший отвечать принтер, разобранный в решении проблемы AirPrint и приватности локальной сети.

Два структурных факта, важных далее. Список, который вы видите, — это отображение базы данных, и баг macOS 26.1, описанный ниже, доказал, что отображение может быть неверным при верной базе. И удаление записи кнопкой - удаляет решение, а не запрещает приложению доступ, поэтому в следующий раз, когда приложение спросит, вы получите новый запрос. Именно на этом различии строится последовательность чистой перевыдачи.

Почему выданное разрешение перестаёт работать

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

TCC привязывается к идентичности подписи кода, а не к пути или имени

Когда вы выдаёте приложению разрешение, macOS не записывает «файлу по адресу /Applications/Foo.app можно записывать экран». Она записывает решение, привязанное к идентичности подписи кода приложения: к его идентификатору и криптографическому требованию, описывающему, кто его подписал. Технотa Apple TN3127, «Inside Code Signing: Requirements», — это справочник по тому, как строятся такие требования.

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

Идентичность приложения можно проверить самостоятельно. На тестовом Mac:

codesign -dv --verbose=2 /System/Applications/Utilities/Terminal.app

В выводе есть строка Identifier — это идентификатор бандла, который использует система (com.apple.Terminal для Terminal), цепочка строк Authority с названиями сертификатов, которыми он подписан, и строка TeamIdentifier. Для собственных встроенных приложений Apple TeamIdentifier показывает not set, потому что Apple подписывает своё системное ПО через другую цепочку доверия, нежели сторонние разработчики. Для стороннего приложения вы должны увидеть десятисимвольный идентификатор команды и цепочку сертификатов, включающую сертификат Developer ID.

Этот идентификатор команды и есть стабильный якорь. Приложение, подписанное ad hoc, без идентификатора команды, опознаётся только по хешу кода, а хеш кода меняется с каждой сборкой. Приложение, подписанное Developer ID, имеет стабильную идентичность команды, переживающую обновления. Именно поэтому одни приложения переспрашивают после каждого обновления, а большинство — нет.

Теперь конкретные случаи.

Случай первый: приложение обновилось и было подписано иначе

Приложение выпустило новую версию. Новая сборка подписана другим сертификатом, или разработчик перешёл от ad-hoc-подписи к Developer ID, или наоборот, или его сертификат истёк и он переподписал новым.

Как распознать: момент точно совпадает с обновлением, и приложение либо исчезло из панели, либо получило вторую запись.

Решение: удалите устаревшую запись и выдайте разрешение заново. Больше делать нечего; с точки зрения TCC это действительно новое приложение.

Случай второй: две копии одного приложения на диске

Это самая частая причина симптома «включено, но не работает» и её проще всего пропустить.

Вы скачали приложение, один раз запустили его из ~/Downloads, выдали разрешение, а позже перетащили в /Applications. Или Homebrew Cask поставил копию, когда одна у вас уже была. Или вы держите релизную сборку в /Applications, а бету в ~/Applications. Панель показывает одну строку с именем и иконкой приложения; она не сообщает, к какой копии эта строка относится. Вы смотрите на разрешение для копии в ~/Downloads, а запускаете копию из /Applications.

Как распознать: найдите все копии на диске.

mdfind "kMDItemKind == 'Application'" -name "AppName"

Или, для более широкого прочёсывания, включающего копии, которые Spotlight мог не проиндексировать:

find /Applications ~/Applications ~/Downloads ~/Desktop -maxdepth 3 -name "AppName.app" 2>/dev/null

Если вернулось больше одного пути — это и есть ваш ответ.

Решение: удалите копии, которые вам не нужны, оставьте ровно одну, затем выполните чистую перевыдачу для выжившей. Не пропускайте удаление: оставив на диске вторую копию, через месяц вы вернётесь сюда снова.

Случай третий: приложение переместили после выдачи разрешения

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

Как распознать: приложение работало, вы переорганизовали папку Applications или восстановились после миграции — и оно сломалось.

Решение: чистая перевыдача по новому расположению. Если приложение переместили во вложенную папку внутри /Applications, сначала попробуйте вернуть его на верхний уровень; несколько приложений с механизмом самообновления плохо ведут себя во вложенных папках.

Случай четвёртый: незавершённое обновление сделало подпись недействительной

Обновление прервалось, синхронизирующая утилита тронула бандл, антивирус поместил файл внутри него в карантин и восстановил, или восстановление из резервной копии собрало бандл неидеально. Подпись больше не проходит проверку.

Как распознать:

codesign --verify --deep --strict --verbose=2 /Applications/AppName.app

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

Решение: переустановите из оригинальной загрузки разработчика. Это один из немногих случаев, когда «переустановите приложение» — действительно правильный ответ, а не пожатие плечами. Родственный и более заметный вариант отказа при том же базовом повреждении — диалог «app is damaged and can't be opened», который мы подробно разбираем в руководстве по Gatekeeper и карантину.

Случай пятый: самообновляющиеся приложения в стиле Sparkle, заменяющие собственный бандл

Многие Mac-приложения, распространяемые вне App Store, обновляют себя через фреймворк Sparkle или нечто похожее: скачивают новую версию и подменяют собственный бандл прямо во время работы.

Когда это работает корректно, новый бандл несёт тот же идентификатор команды, и TCC продолжает его узнавать. Когда не работает — потому что обновление подписано иначе, или подмена оставила частично записанный бандл, или приложение заменило себя по чуть другому пути — вы получаете повторный запрос или молчаливый отказ при следующем использовании защищённой функции.

Как распознать: приложение обновляет себя вне App Store, и проблемы с разрешениями группируются вокруг моментов обновления.

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

Общая диагностика

Столкнувшись с любым случаем «выдано, но не работает», задайте три вопроса по порядку: сколько копий этого приложения есть на диске (mdfind), проходит ли бандл проверку (codesign --verify) и сломалось ли оно сразу после обновления? Эти три ответа почти всегда указывают на один из пяти случаев выше.

Инструменты Terminal: что tccutil может и чего не может

Для этой подсистемы существует ровно одна утилита командной строки, и её возможности гораздо уже, чем подразумевает большинство руководств.

reset — единственная команда

Запустите tccutil без аргументов на macOS 26.5.2, и она выведет строку использования:

tccutil: Usage: tccutil reset SERVICE [BUNDLE_ID]

Это весь интерфейс. Страница man от Apple прямо говорит, что «one command is currently supported», и описывает её так:

reset Reset all decisions for the specified service, causing apps to prompt again the next time they access the service. If a bundle identifier is specified, the service will be reset for that bundle only.

Собственные примеры Apple в man-странице — tccutil reset AddressBook и tccutil reset All com.apple.Terminal.

Сделайте вывод, который большинство руководств пропускает: команды grant не существует. Одобрить разрешение из Terminal нельзя. reset забывает решение, чтобы приложение спросило снова; он не говорит «да» за вас. Сказать «да» можно только через интерфейс System Settings и через конфигурационный профиль MDM. Если вам попалось руководство с заклинанием tccutil, якобы выдающим Full Disk Access, оно ошибается.

Предупреждение об идентификаторе бандла, которое важнее всего

Это практическое ядро всего раздела о Terminal, поэтому ему отведено отдельное место.

# DANGEROUS - resets screen recording for EVERY app on the Mac
tccutil reset ScreenCapture

# Correct - resets it for one app only
tccutil reset ScreenCapture com.example.appname

Идентификатор бандла необязателен по синтаксису и обязателен на практике. Опустите его — и вы приказали macOS забыть все решения о записи экрана на машине. Zoom, Slack, Discord, Teams, ваш инструмент для скриншотов, ваша программа записи, ваш клиент удалённой поддержки — все они спросят вас снова при следующем использовании. Ничего не сломано навсегда, но вы устроили себе полдня диалоговых окон в попытке починить одно приложение.

tccutil reset All без идентификатора бандла ещё хуже: он забывает все решения по всем службам для всех приложений. Если руководство советует запустить это первым шагом, закройте руководство.

Всегда дописывайте идентификатор бандла. Каждый раз, без исключений.

Порядок проверки аргументов и почему он может скрыть опечатку

Это было проверено напрямую, и такое поведение влияет на то, как вы читаете ошибки. tccutil проверяет идентификатор бандла раньше имени службы. Дайте ей одновременно несуществующую службу и несуществующий bundle ID:

tccutil reset ZZZNotAService com.example.nonexistent.zzz

и она вернёт:

tccutil: No such bundle identifier "com.example.nonexistent.zzz": The operation couldn't be completed. (OSStatus error -10814.)

Она жалуется на бандл, а не на очевидно неверное имя службы. Дайте ей несуществующую службу вообще без bundle ID:

tccutil reset ZZZNotAService

и она вернёт:

tccutil: Failed to reset ZZZNotAService

Практическое следствие: опечатка в идентификаторе бандла всегда даёт понятную, конкретную ошибку — и это хорошо. Но опечатку в имени службы может замаскировать одновременно неверный идентификатор бандла, потому что утилита просто не доходит до того места, где могла бы на неё пожаловаться. Если вы получили ошибку -10814, сначала исправьте идентификатор бандла, затем запустите команду снова и посмотрите, не было ли ошибочным и имя службы.

Отсюда следствие: проверяйте идентификатор бандла до того, как соберёте команду.

Как узнать идентификатор бандла приложения

Есть два надёжных способа. Первый был проверен на тестовом Mac, где osascript -e 'id of app "Terminal"' вернула com.apple.Terminal, а osascript -e 'id of app "Safari"' вернула com.apple.Safari:

osascript -e 'id of app "AppName"'

Подставьте имя приложения так, как оно отображается в Finder. Это самый быстрый способ, и именно его подсказали читатели Ховарда Оукли в комментариях к его обзору защиты приватности, что он и отметил.

Второй способ читает бандл напрямую и полезен, когда приложение находится в нестандартном месте или AppleScript не может разрешить имя:

defaults read /Applications/AppName.app/Contents/Info.plist CFBundleIdentifier

Либо воспользуйтесь просмотром подписи кода, который заодно показывает подписывающий центр, и прочитайте строку Identifier=:

codesign -dv --verbose=2 /Applications/AppName.app

Используйте что вам удобнее, но используйте что-нибудь из этого. Не угадывайте идентификатор по имени приложения. Обратная нотация DNS — это соглашение, а не правило, и у множества приложений идентификаторы не имеют ничего общего с тем, что вы бы предположили.

Имена служб — это знание сообщества, а не документация Apple

Здесь честность важнее полноты.

Apple не публикует список имён служб, которые принимает tccutil reset. Страница man даёт ровно два в качестве примера: AddressBook и All. Это вся документация Apple по данному вопросу.

Названия, ходящие в обиходе, идут от сообщества. Ховард Оукли опубликовал список в своём обзоре защиты приватности от марта 2025 года, куда среди прочего входят:

Accessibility, AddressBook, All, AppleEvents, AudioCapture, BluetoothAlways, Calendar, Camera, ContactsFull, ContactsLimited, DeveloperTool, FocusStatus, MediaLibrary, Microphone, Motion, Photos, PostEvent, Reminders, RemoteDesktop, ScreenCapture, SpeechRecognition, SystemPolicyAllFiles, SystemPolicyDesktopFolder, SystemPolicyDocumentsFolder, SystemPolicyDownloadsFolder, SystemPolicyNetworkVolumes, SystemPolicyRemovableVolumes.

Два из них соответствуют панелям, которым эта статья уделяет больше всего внимания: ScreenCapture для Screen & System Audio Recording и SystemPolicyAllFiles для Full Disk Access.

Я намеренно не проверял эти имена перебором на тестовом Mac. tccutil reset, который срабатывает, стирает реальные разрешения машины, так что единственный способ подтвердить работоспособность имени — уничтожить то, что вы пытались сохранить, а проверка тех, что не срабатывают, не говорит ничего. Список выше — это хорошо подкреплённое источниками знание сообщества, совпадающее с тем, что практики используют в работе. Это не документация Apple, и я предпочту сказать об этом прямо, а не выдавать его за авторитетный источник.

Отсюда два вывода. Если tccutil reset вроде бы ничего не делает, рассмотрите вариант, что имя службы неверно, прежде чем заключать, что система сломана. И по возможности предпочитайте путь через System Settings, потому что в панели не бывает орфографических ошибок.

Бинарники командной строки и вспомогательные утилиты

Это та область, где модель «одно приложение — одна запись в списке» ломается сильнее всего и где хорошо задокументированный баг macOS 26 на некоторое время значительно всё усугубил.

У простого исполняемого файла нет идентификатора бандла

.app — это бандл: каталог с определённой структурой, содержащий Info.plist, который объявляет, среди прочего, CFBundleIdentifier. У скомпилированного бинарника, лежащего в /usr/local/bin, ничего этого нет. Это просто исполняемый файл Mach-O.

Модель TCC построена вокруг бандлов. Простому исполняемому файлу разрешение всё ещё можно выдать, но у него нет идентификатора бандла, за который можно зацепиться, — поэтому он может не появляться в панели так, как это делает приложение, и поэтому tccutil reset Service bundle.id нечего для него нацелить.

Баг отображения в macOS 26.1 и чему он всех научил

В конце 2025 года группа тредов на Apple Developer Forums сообщала об одном и том же по разным разрешениям. Их стоит разобрать, потому что диагноз подтвердили собственные инженеры Apple, а исход говорит кое-что долговечное о том, как панель соотносится с базой данных.

Тред 807898, «Issue: Plain Executables Do Not Appear Under 'Screen & System Audio Recording' on macOS 26.1 (Tahoe)», сообщал, что простой исполняемый файл, запрашивающий запись экрана, получает обычный запрос, после выдачи корректно снимает экран, но никогда не появляется в списке System Settings. Резюме автора: «macOS 26.1 (Tahoe) appears to require app bundles for an item to be shown in the Screen Recording privacy UI. Plain executables: still request and receive permission, still function correctly after permission is granted, but do not appear in the System Settings list». Тот же код, упакованный в бандл .app, отображался нормально. Куинн «The Eskimo!», инженер DTS в Apple, ответил, подтвердив это: «IMO this is a bug and I encourage you to file it as such».

Тред 807323, «Background Unix executable not appearing in Screen Recording permissions UI (macOS Tahoe 26.1)», сообщал о том же симптоме с другой стороны. Фоновый Unix-исполняемый файл, вызывающий CGRequestScreenCaptureAccess(), работал на 26.0.1 и перестал появляться в интерфейсе на 26.1. Автор отметил, что ручное добавление исполняемого файла кнопкой + «grants permission internally, but the executable still doesn't show in the UI», так что пользователи «cannot verify or revoke permissions». На тот тред Apple не ответила, было только подтверждение от другого разработчика. Тред 809549 поднял ту же проблему для Full Disk Access, сообщив, что бинарники командной строки «fail to appear under the FDA settings, even after selection»; Куинн перенаправил его в существующий сводный тред, а модератор закрыл обсуждение.

Этот сводный тред, 806187, и есть место, где живёт разгадка. Ключевой вывод: разрешения всё это время записывались корректно. База данных была права; список был неправ. Как выразился один из участников, «CLI apps can have full disk access or other permissions, but you cannot see it in the list». Функция «Background Security Improvements», добавленная в 26.1, изменила интерфейс настроек так, что он показывал только приложения-бандлы.

Временный обходной путь состоял в том, чтобы «drag the binary from Finder to the full disk access list in System Settings window. The permission will be given, but it won't show in the list». Долговечная рекомендация пришла от Кевина Эллиотта, ещё одного инженера DTS: «The better solution is to embed that tool inside an app bundle. I don't mean 'make your command-line tool act like an app', I mean 'take your command-line tool and stick it inside an app bundle, then use it exactly the way you were using it before'».

Несколько участников подтвердили, что баг отображения был исправлен в бете macOS 26.3, а кто-то в треде 807898 сообщил, что параллельная версия проблемы для Accessibility, присутствовавшая в 26.1 и бете 26.2, тоже была решена в 26.3.

Почему это важно для вас, даже если вы уже прошли 26.1: панель — это представление базы данных, а представления могут врать. Если у приложения или утилиты разрешение явно есть, но в списке они не появляются, не считайте, что разрешение отсутствует. Проверьте поведение, прежде чем начинать что-то сбрасывать.

Почему приложение, запущенное из Terminal, наследует разрешения Terminal

На этом постоянно спотыкаются разработчики, и, как только вы узнаёте правило, загадка исчезает.

TCC не просто спрашивает «какой бинарник делает этот запрос?». Он проходит по тому, что Ховард Оукли описывает как «an attribution chain that traces up through the call chain to an app that is responsible for the privacy settings to be applied». Система ищет ответственный процесс, которым обычно оказывается приложение, запущенное пользователем, а не самый глубокий процесс в цепочке.

Поэтому, когда вы запускаете программу из Terminal, ответственным процессом обычно является Terminal. Запрос вашей программы на захват экрана становится запросом Terminal на захват экрана. Если у Terminal разрешение есть, ваша программа работает; если нет, в запросе будет назван Terminal, а не ваша программа. Именно это наблюдал автор треда 807898: при запуске из другого приложения, например VS Code или Terminal, «the parent app appears in the list instead, not the executable itself».

Три следствия в повседневной работе. Выдача разрешения вашему эмулятору терминала означает, что каждый запускаемый в нём инструмент наследует это разрешение — это удобно и одновременно является реальным расширением привилегий, о котором стоит подумать, прежде чем делать это походя. Один и тот же скрипт ведёт себя по-разному при запуске из Terminal, из LaunchAgent и из обёртки-приложения по двойному клику, потому что ответственный процесс в каждом случае разный. И смена эмулятора терминала означает начать сначала, поскольку iTerm2, Ghostty, Warp, Kitty и Terminal.app — каждый из них отдельная идентичность.

Вспомогательные утилиты, XPC-службы и объекты входа

Современное Mac-приложение часто состоит из нескольких исполняемых файлов: основного приложения, возможно, привилегированного хелпера в /Library/PrivilegedHelperTools, возможно, XPC-служб, встроенных в бандл, возможно, агента запуска, работающего при входе в систему.

Встроенные XPC-службы внутри корректно подписанного бандла, как правило, работают под атрибуцией родительского приложения, потому что цепочка разрешается до приложения. Отдельно устанавливаемые хелперы и launch daemons — часто нет: они работают вне дерева процессов приложения со своей собственной идентичностью и нуждаются в собственном разрешении. Именно поэтому некоторые приложения просят одобрить разрешение дважды — один раз для приложения и один раз для его хелпера — и почему хелперу, установленному от root, может понадобиться запись в системной базе, а не в вашей пользовательской.

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

Отдельно о записи экрана

Панель находится по пути System Settings → Privacy & Security → Screen & System Audio Recording. Описание Apple дословно: «Allow apps to record your screen and audio, or just your audio. The listed apps have access».

Моменты, специфичные для этого разрешения:

Это единственное разрешение с плановым повторным запросом. Ни одна другая категория TCC не переспрашивает по таймеру. Если разрешение на камеру или Full Disk Access запрашивается у вас ежемесячно, это не задуманное поведение и у вас неисправность.

После переключения обычно требуется перезапуск приложения. Многие приложения считывают возможность захвата один раз при запуске. Включите переключатель, пока приложение работает, и оно может не заметить этого до перезапуска. Одно это объясняет большую часть сообщений вида «я включил, и ничего не произошло».

Системный звук и экран сгруппированы, но не идентичны. Панель охватывает и то и другое. Некоторые приложения запрашивают только звук. Если приложение нормально снимает экран, но записывает тишину, посмотрите, запрашивало ли оно вообще захват системного звука, и проверьте настройки звуковых устройств в самом приложении, потому что отсутствующее виртуальное аудиоустройство — это совершенно отдельная проблема, не связанная с TCC. Полное руководство по записи экрана на Mac подробно разбирает звуковую сторону.

Сложный случай из реальной жизни, изложенный честно. Тред Microsoft Q&A документирует Teams для Mac на macOS Tahoe 26.4, сборка 25E246, зацикливающийся на запросе разрешения демонстрации экрана. Сообщивший об этом администратор проверил всё, что человек в принципе может проверить: развёрнутый через MDM профиль PPPC, нацеленный на com.microsoft.teams2 с корректным требованием кода; системную запись TCC, показывающую auth_value=2 для kTCCServiceScreenCapture; пользовательскую запись с тем же значением; и System Settings, где Teams включён с примечанием, что настройка задана профилем. Они очистили кеши, убрали устаревший идентификатор com.microsoft.teams, переустановили через MDM, завершили и перезапустили процессы и перезагрузились.

Предложенные ответы были стандартной процедурой: «fully quit Teams, remove and re-add or re-toggle the Teams entry in Screen Recording, then restart Teams and re-attempt sharing so macOS can re-prompt and re-bind the permission», а если это не помогает — эскалировать в поддержку Microsoft с логами клиента. Три недели спустя автор сообщил, что рабочего решения предоставлено не было и он вместо этого пользуется веб-версией. Иногда разрешение действительно выдано на всех уровнях, а виноват баг на стороне приложения. Понимать, когда пора остановиться, — тоже часть мастерства.

Отдельно о Full Disk Access

Full Disk Access — самое широкое разрешение в системе. Оно нужно программам резервного копирования, утилитам миграции, защитному ПО и эмуляторам терминала, используемым для администрирования.

Это не то же самое, что записи в Files and Folders. Files and Folders даёт доступ к конкретной папке. Full Disk Access даёт защищённые данные по всей машине: Mail, Messages, данные просмотра Safari, резервные копии Time Machine и каталоги контейнеров других приложений. Приложению с Full Disk Access ничего не нужно в Files and Folders.

Почти всегда требуется перезапуск приложения. Больше, чем любое другое разрешение, Full Disk Access обычно оценивается при старте процесса. Выдайте его, затем закройте и запустите приложение заново. Многие приложения показывают диалог, предлагающий сделать ровно это; верьте им.

Его нельзя запросить через диалог. Приложение не может вывести окно, которое выдаст Full Disk Access при одобрении; оно может только отправить вас в панель. Именно поэтому приложения, которым оно нужно, показывают инструкции, а не системный диалог, и почему «я нажал Allow, и всё равно не работает» — частое сообщение: никакого Allow там и не было.

Для эмулятора терминала это разрешение очень широкое. Выдав Terminal или iTerm2 Full Disk Access, вы даёте такой охват каждой команде, которую в нём запускаете, — через описанную ранее цепочку атрибуции. Часто это именно то, чего хочет администратор. Просто понимайте, что именно вы делаете.

Инструменты командной строки затрагивал баг отображения 26.1, описанный выше, с исправлением в бете 26.3. Если вы на 26.1 или 26.2 и CLI-инструмент отказывается появляться в списке после добавления, это тот самый известный баг, и разрешение у инструмента вполне может быть. Проверяйте фактическое поведение, а не доверяйте списку.

Отдельно об Accessibility и Automation

Эти два объединены, потому что порождают схожий класс путаницы.

Accessibility даёт приложению возможность управлять вашим Mac. Оконные менеджеры, расширители текста, менеджеры буфера обмена, переназначатели клавиш, инструменты автоматизации и ПО удалённой поддержки — всем им это нужно, и macOS относится к этому как к мощному разрешению, каковым оно и является.

Его отличительное поведение: многим приложениям требуется полный выход и перезапуск, а некоторым — выключить и снова включить переключатель, прежде чем изменение вступит в силу. Если зависящее от Accessibility приложение перестало работать после обновления, сначала проверьте случаи с идентичностью подписи кода, описанные выше. Accessibility также была одной из панелей, затронутых багом отображения macOS 26.1: в треде 807898 сообщалось, что вариант проблемы для Accessibility «has now been fixed in 26.3 Beta».

Automation структурно отличается от всех остальных панелей. Это не список приложений, а список пар: «App A хочет управлять App B», и каждая пара — отдельное решение. Если ваш скрипт управляет тремя приложениями, у вас три решения и три записи.

Отсюда два следствия. Сломанное разрешение Automation часто означает, что отсутствует одна пара из нескольких, и панель — единственное место, где видно, какая именно. И сброс Automation командой tccutil reset AppleEvents com.example.controller очищает все пары этого управляющего приложения разом, так что вам придётся заново одобрить каждую цель, когда ваш скрипт к ней обратится. Часто это самый быстрый выход из застрявшего состояния Automation, но будьте готовы к череде запросов.

Одна ловушка, которую стоит назвать: запустите AppleScript из Terminal — и записанным разрешением будет «Terminal управляет целевым приложением», а не «ваш скрипт управляет им». Перенесите скрипт в другой эмулятор терминала или заверните его в приложение — и вы будете одобрять всё заново. Это цепочка атрибуции, работающая как задумано, что не делает её менее неожиданной в первый раз.

Последовательность чистой перевыдачи

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

1. Полностью закройте приложение.

Не просто закройте его окно. Завершите его через Cmd-Q, затем убедитесь, что ничего не осталось:

pgrep -fl "AppName"

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

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

2. Убедитесь, что на диске ровно одна копия приложения.

mdfind "kMDItemKind == 'Application'" -name "AppName"

Удалите любую копию, которой не пользуетесь.

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

3. Подтвердите идентификатор бандла.

osascript -e 'id of app "AppName"'

Почему: неверный идентификатор в лучшем случае даст вам ошибку -10814, а в худшем — соблазнит вовсе убрать идентификатор из команды сброса, а это разрушительный путь.

4. Удалите запись приложения из панели.

Откройте System Settings → Privacy & Security → нужную панель, выберите приложение, нажмите -. Если запросят аутентификацию администратора, введите её.

Почему: это удаляет устаревшее решение через поддерживаемый интерфейс. Это не то же самое, что выключить переключатель, что записывает запрет, а не удаляет решение. Запрет означает, что приложению больше не позволят вас спрашивать.

5. Сбросьте службу для этого идентификатора бандла.

tccutil reset ScreenCapture com.example.appname

Подставьте правильное имя службы и идентификатор. SystemPolicyAllFiles для Full Disk Access, Accessibility для Accessibility, AppleEvents для Automation.

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

6. Запустите приложение заново.

Почему: свежий процесс без кешированного решения и без остатков от предыдущего запуска.

7. Выполните действие, требующее разрешения.

Начните демонстрацию экрана. Откройте папку. Отправьте Apple event. Не возвращайтесь в System Settings, чтобы заранее включить переключатель.

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

8. Одобрите в запросе.

Нажмите Allow либо откройте System Settings и включите там, если приложение относится к категориям, которые не могут запросить напрямую, таким как Full Disk Access.

9. Ещё раз закройте и запустите приложение.

Почему: многие приложения считывают набор своих возможностей только при запуске. Этот шаг превращает «выдано» в «действительно работает» и устраняет самый частый ложноотрицательный результат во всей процедуре.

Если после девятого шага приложение всё ещё не работает, проблема не в разрешении. Переходите к следующему разделу.

Когда ничего не помогает

Проверьте на новой учётной записи

Создайте новую учётную запись администратора в System Settings → Users & Groups, войдите в неё, установите или запустите приложение и выдайте разрешение там.

Одна эта проверка чётко разделяет пространство проблем:

• Работает в новой учётной записи: неисправность в состоянии вашей учётной записи — скорее всего, в пользовательской базе TCC, устаревшей настройке или мешающем объекте входа. С приложением и системой всё в порядке.
• Не работает и в новой учётной записи: неисправность общесистемная либо в самом приложении. Ваша учётная запись ни при чём, и множество советов «удалите ваши настройки», которые вы собирались попробовать, потратили бы ваш вечер впустую.

Это занимает пять минут и стоит больше, чем час гаданий.

Когда полная переустановка действительно является ответом

Переустановка — рефлекторный ответ на всё, и обычно она неверна. По-настоящему она права в трёх ситуациях:

1. codesign --verify сообщает, что бандл повреждён. Подпись не проходит проверку; ничто из того, что дальше по цепочке, починить нельзя. Переустановите из оригинальной загрузки разработчика, а не из резервной копии, потому что резервная копия может быть источником повреждения.
2. Приложение было установлено из источника, который его изменил. Перепакованные инсталляторы, инструменты, патчащие бандлы приложений, и некоторые механизмы корпоративного развёртывания оставляют бандл, подпись которого больше не совпадает с подписью разработчика. Возьмите чистую копию у разработчика.
3. Собственная документация поддержки приложения так говорит применительно к вашему конкретному симптому. У некоторых приложений есть известные проблемы с состоянием разрешений и задокументированные процедуры переустановки, включая шаги по очистке их собственных каталогов состояния.

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

Перезагрузка — но по правильной причине

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

Чего делать не нужно

Скажем прямо, потому что это постоянно попадается в результатах поиска: не отключайте SIP — это снимает защиту со всей системы ради обхода диалогового окна. Не редактируйте и не удаляйте TCC.db — при включённой SIP вы этого сделать не сможете, а при выключенной не должны хотеть. Не делайте chmod -R для вашей домашней папки — это не затрагивает данную подсистему и может сломать папку Library. И не запускайте tccutil reset All без идентификатора бандла, если только не хотите провести остаток дня, нажимая Allow.

Управляемые Mac

Если ваш Mac администрируется работодателем или учебным заведением, правила меняются, и стоит выяснить, относится ли это к вам, прежде чем потратить час на борьбу с переключателем, который вам всё равно было не победить.

Как понять, что ваш Mac управляемый

Три проверки. Первая: посмотрите System Settings → General → Device Management. Если профиль установлен, он будет там указан. Вторая: поищите примечание в самой панели приватности — управляемая запись отображает текст о том, что настройка задана профилем, и её переключатель обычно неактивен. Третья — из Terminal:

profiles status -type enrollment

На неуправляемом тестовом Mac это вернуло:

Enrolled via DEP: No
MDM enrollment: No

Управляемый Mac вместо этого сообщит о зачислении.

Что профиль может и чего не может

MDM выдаёт разрешения через полезную нагрузку Privacy Preferences Policy Control, обычно называемую профилем PPPC. Она записывает решения напрямую в общесистемную базу TCC — именно поэтому у управляемого Mac могут быть разрешения, появившиеся без чьих-либо кликов.

Ограничения есть, и захват экрана — одно из них. Kandji, MDM-вендор, чей разбор изменений PPPC широко цитируется среди Mac-администраторов, описывает механизм: для захвата экрана и мониторинга ввода «IT can use MDM to pre-allow certain apps to be approved even by standard users to enable screen capture or input monitoring». Здесь используется значение авторизации, делегирующее одобрение пользователю, а не выдающее разрешение молча. То есть профиль может запретить захват экрана полностью и может позволить обычному пользователю его одобрить, но задокументированное поведение таково, что он не выдаёт его молча, как это возможно для Full Disk Access или Accessibility.

Относитесь к этому нюансу с осторожностью, потому что в описанном выше случае Microsoft Q&A администратор сообщал о системной записи TCC для kTCCServiceScreenCapture с причиной авторизации, указывающей на политику MDM. Эти два свидетельства не складываются друг с другом аккуратно, и я привожу оба, а не выбираю то, что выглядит опрятнее.

Если вы пользуетесь управляемым Mac

Не пытайтесь обойти неактивный переключатель. У вас не получится, а на многих развёртываниях сама попытка логируется. tccutil reset в отношении записи, управляемой профилем, либо не сработает, либо будет заново применён при следующей проверке связи с системой управления. Обратитесь к тем, кто управляет вашим парком устройств; исправление — это изменение профиля на их стороне, и оно занимает минуту.

Если вы администрируете управляемые Mac

Приведите требование кода в полезной нагрузке PPPC в соответствие с тем, что codesign фактически сообщает для развёрнутой версии приложения. Случай с Teams выше показателен именно потому, что администратор это проверил и всё равно упёрся в стену: корректный профиль необходим, но не всегда достаточен. Когда приложение меняет идентификатор бандла между версиями, как это сделал Teams, удаляйте устаревший идентификатор из профиля, а не оставляйте оба.

Устранение типичных неполадок

Приложение есть в списке и включено, но всё равно не может записывать

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

Решение: запись привязана к идентичности подписи, которая больше не совпадает с приложением на диске. Сначала запустите mdfind "kMDItemKind == 'Application'" -name "AppName", чтобы проверить наличие второй копии — это самая частая причина — и удалите лишние. Затем выполните полную последовательность чистой перевыдачи, включая и удаление из панели, и tccutil reset с идентификатором бандла. Не просто выключайте и включайте переключатель: это записывает запрет, за которым следует непривязанное одобрение, и именно так вы сюда и попали.

Приложение исчезло из списка после обновления

Проблема: приложение, которое вчера было в панели, сегодня в ней отсутствует, и единственное, что изменилось, — обновление.

Решение: новая сборка подписана иначе, поэтому macOS видит новое приложение без истории. Чинить нечего: запустите приложение, выполните защищённое действие, одобрите новый запрос. Если приложению нужен Full Disk Access, который не может запрашиваться диалогом, добавьте его кнопкой +. Если это повторяется при каждом обновлении, настройка подписи у разработчика нестабильна, и об этом стоит ему сообщить.

Запрос при каждом запуске, а не раз в месяц

Проблема: диалог захвата экрана появляется каждый раз при открытии приложения, а не по ожидаемому расписанию.

Решение: это неисправность, а не задуманный повторный запрос. Вероятные причины: приложение с ad-hoc-подписью, чей хеш кода меняется с каждой сборкой; самообновляющийся механизм, раз за разом заменяющий бандл; или путь запуска, отличающийся каждый раз. Запустите codesign -dv --verbose=2 для приложения и посмотрите на строку TeamIdentifier. Если у стороннего приложения там not set, значит, оно не подписано Developer ID, и стабильное разрешение недостижимо, пока разработчик не исправит свою подпись.

Две записи с одинаковым именем приложения

Проблема: панель показывает одно и то же приложение дважды, иногда с одинаковыми иконками.

Решение: на диске есть две копии с разными идентичностями подписи или разными путями. Найдите их все через find /Applications ~/Applications ~/Downloads ~/Desktop -maxdepth 3 -name "AppName.app" 2>/dev/null. Оставьте одну, остальные удалите, уберите обе записи из панели, затем выдайте разрешение выжившей. Если вы намеренно держите бета-канал рядом с релизной сборкой, ожидайте и принимайте две записи.

Инструмент командной строки не появляется в списке

Проблема: вы добавляете бинарник кнопкой +, и он не отображается.

Решение: на macOS 26.1 и 26.2 это подтверждённый баг отображения, обсуждавшийся выше, признанный инженерами DTS Apple и, по сообщениям, исправленный в бете 26.3. Разрешение с очень высокой вероятностью записывается, даже если список этого не показывает, поэтому проверьте фактическое поведение, прежде чем продолжать поиск неисправности. На любой версии простые исполняемые файлы не имеют идентификатора бандла и никогда не были полноправными гражданами этого интерфейса. Долговечный ответ, словами Кевина Эллиотта из треда 806187, — поместить инструмент внутрь бандла приложения и продолжать пользоваться им ровно как прежде.

В запросе названо не то приложение

Проблема: вы запускаете скрипт, а в диалоге разрешения назван Terminal, или VS Code, или Script Editor, а не ваш скрипт.

Решение: это корректно работающая цепочка атрибуции. Ответственный процесс — это приложение, которое вы запустили, и разрешение привязывается к нему. Либо выдайте разрешение этому приложению-хосту и примите, что всё запускаемое внутри него наследует это разрешение, либо упакуйте свой инструмент как отдельный бандл приложения, чтобы он стал ответственным процессом. Учтите, что смена эмулятора терминала означает повторную выдачу, потому что каждый из них — отдельная идентичность.

Переключатель неактивен

Проблема: вы не можете изменить переключатель, и, возможно, рядом есть примечание о профиле.

Решение: решение задано конфигурационным профилем. Подтвердите это через profiles status -type enrollment и проверьте System Settings → General → Device Management. На управляемом Mac обратитесь к администратору; изменение должно произойти в профиле. На личном Mac с неожиданно появившимся профилем изучите, что там установлено, потому что профиль, который вы не устанавливали осознанно, заслуживает пристального внимания.

Разрешение работает, а потом перестаёт после сна или долгой сессии

Проблема: демонстрация экрана работает в начале дня и отказывает после того, как Mac побывал в режиме сна.

Решение: сначала проверьте, не является ли то, что вы наблюдаете, диалогом периодического переподтверждения, появившимся за другим окном, поскольку запрос, которого вы не увидели, выглядит ровно как молчаливый отказ. Выведите все окна на передний план и посмотрите. Если запроса нет, полностью закройте приложение, убедитесь в этом через pgrep -fl "AppName" и запустите заново, поскольку обычный виновник — процесс-хелпер, не сумевший перезагрузиться после пробуждения. Если сохраняется, перезагрузите Mac один раз. Если это повторяется ежедневно, у приложения баг в обработке пробуждения, и место ему в отчёте разработчику.

FAQ

Можно ли отключить периодический запрос разрешения на запись экрана?

Нет. Apple не предоставляет пользовательской настройки для его отключения, и нет поддерживаемой команды, которая бы его подавляла. Единственный механизм, который его убирает, — entitlement com.apple.developer.persistent-content-capture, управляемая возможность, на которую разработчики должны подавать заявку в Apple, ориентированная на приложения удалённого управления. Пользователь включить её не может.

Как часто macOS переспрашивает разрешение на запись экрана?

Apple никогда не документировала интервал. Поведение началось в цикле Sequoia как еженедельное, и Apple изменила его на ежемесячное в ходе той беты после критики, о чём в августе 2024 года сообщали MacRumors и 9to5Mac. Текущая страница поддержки Apple не упоминает повторные запросы вообще, и мне не удалось подтвердить периодичность для macOS 26 ни по одному авторитетному источнику.

Удалит ли сброс разрешений мои данные?

Нет. tccutil reset удаляет записанные решения о согласии, и ничего больше. Никакие файлы, настройки или данные приложений не затрагиваются. Цена — неудобство: каждое затронутое приложение спросит снова, когда ему в следующий раз понадобится разрешение. Эта цена растёт вместе с широтой вашего сброса, и именно поэтому всегда следует указывать идентификатор бандла.

Почему моё приложение работает в Terminal, но не само по себе?

Потому что TCC приписывает запрос ответственному процессу, которым для программы, запущенной из Terminal, обычно является сам Terminal. Ваша программа заимствует разрешение Terminal. Сама по себе она разрешения не имеет и, если это простой исполняемый файл, а не бандл приложения, может даже не появиться в панели, чтобы его получить.

Опасно ли выдавать Full Disk Access?

Это самое широкое разрешение, которое предлагает macOS: оно охватывает Mail, Messages, данные Safari, резервные копии Time Machine и контейнеры других приложений. Выдавайте его только тому ПО, которому вы доверили бы всё перечисленное, и учтите, что выдача его эмулятору терминала распространяет этот охват на каждую команду, которую вы там запускаете.

Нужно ли перезагружать Mac после изменения разрешения?

Обычно нет. Закрыть и заново запустить затронутое приложение почти всегда достаточно, и это обязательный шаг, потому что многие приложения считывают свои возможности только при запуске. Полная перезагрузка помогает в более узком случае, когда фоновый хелпер или launch daemon не перезагружается корректно. Перезагрузитесь один раз, а затем вернитесь к диагностике.

Заключение

Большая часть раздражения в этой области возникает от того, что одно слово — «разрешения» — воспринимается как одна сущность. На деле их как минимум три: права доступа к файлам POSIX, которыми управляет chmod и которые не имеют ко всему этому никакого отношения; решения приватности TCC, привязанные к идентичности подписи кода приложения и хранящиеся в базах, которые вы не можете прочитать; и, на управляемых Mac, записанная профилем политика, перекрывающая то, что вы можете менять локально.

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

Инструментарий действительно скудный. У tccutil один глагол, Apple не публикует принимаемые им имена служб, а панель — это представление базы данных, которое уже доказанно бывало неверным, как показал баг отображения macOS 26.1, когда собственные инженеры Apple подтвердили, что разрешения записывались корректно, а список отказывался их показывать. Работайте в этих рамках: проверяйте идентификатор бандла до сборки команды, всегда дописывайте его к reset, выполняйте последовательность чистой перевыдачи по порядку и проверяйте на новой учётной записи, когда зашли в тупик. И знайте, когда остановиться. Когда вы проверили выдачу, проверили подпись, устранили дубликаты и протестировали в чистой учётной записи, как это сделал автор сообщения о Teams на macOS Tahoe 26.4, оставшаяся проблема — не ваша забота. Сообщите о ней и пользуйтесь обходным путём, пока ждёте.

Дополнительное чтение: Микрофон Mac не работает на macOS Tahoe 26.5 · Безопасность и приватность macOS Tahoe: полное руководство