macos-privacy-permissions-workflow

macOS Privacy Permissions Workflow

Purpose

Identify the protected operation, responsible executable, and current public authorization contract before changing code or asking the person to change Privacy & Security settings. Keep project declarations, user consent, managed policy, and runtime success as separate evidence.

When To Use

• Use for macOS privacy authorization failures, permission prompts, Settings entries, tccutil reset, PPPC policy, and responsible-code attribution.
• Use for Accessibility, Automation, Developer Tools, screen/system-audio recording, Input Monitoring, camera, microphone, personal data, Files and Folders, Full Disk Access, App Management, and other current macOS privacy classes.
• Do not use private TCC APIs or database details as an application implementation contract.

Single-Path Workflow

1. Record the exact attempted operation, target resource or process, timestamp, user/session, error domain/code/message, and whether the evidence came from the host, a guest, or a physical Mac.
2. Resolve the responsible code: executable path, bundle identifier, Team ID, designated requirement, signing state, parent/launcher, helper or XPC boundary, and whether the artifact changed. Read references/responsible-code-and-attribution.md.
3. Apply the Apple docs gate through explore-apple-swift-docs. Record the host macOS version/build and selected SDK/Xcode, then verify the current framework API and settings name. Do not promote an internal service string to a public API.
4. Select the class in references/permission-class-matrix.md. Inspect the relevant usage description, entitlement/capability, sandbox state, helper identity, and final signed artifact without treating any declaration as consent.
5. Preflight or read status using the class's documented public API when one exists. Preserve .notDetermined, restricted or managed, denied, limited, and authorized states instead of collapsing them to Boolean access.
6. Request only from the user action that needs access and only when the public API supports requesting. Explain the operation, system UI, denial behavior, later Settings path, and any relaunch/helper restart/logout requirement.
7. For Settings-managed classes such as Full Disk Access, describe the user or MDM decision and the narrow responsible executable. Never invent a self-grant API or grant a broad terminal, IDE, or agent host without explaining its broader authority.
8. Read references/prompting-settings-reset-and-mdm.md before resetting or managing state. Treat tccutil reset as test-state removal, never grant or general status inspection.
9. Reproduce the original operation after the required lifecycle transition. Record the status/preflight result, actual operation result, responsible executable, mutations and approvals, reset/rollback path, and remaining uncertainty.
10. Use the minimum fixture in references/validation-fixtures.md. Obtain explicit approval immediately before any visible prompt, System Settings change, logout, or live-host permission mutation.