Apple Debug MCP is a privileged local developer tool. It can start debuggers and, when explicitly enabled, alter an authorized target. The default process is read-only discovery and inspection; every state-changing boundary is opt-in and scoped.

• The MCP client is the local caller and may start the server through stdio or connect to the authenticated loopback daemon endpoint.
• The server inherits the caller’s macOS identity and developer-tool permissions.
• Xcode, LLDB, Simulator, CoreDevice, and unified logging are external authority-bearing tools.
• Checkpoint artifacts are local evidence files; replay relaunches only the previously authorized local macOS launch target and does not restore arbitrary process or kernel state.
• Kernel-lab sessions are a separate user-authorized two-machine boundary; KDK, KDP, SIP, boot security, and target preparation remain outside MCP automation.
• A physical iOS device and its development-signed application are separate trust targets.
• Stock App Store applications are outside the supported target boundary.

Symbolication is fail-closed and non-executing. The caller supplies every artifact path; the resolver requires an absolute path, canonicalizes it, and allows a bundle child or symlink only when its canonical target remains inside the supplied .app or .dSYM root. The resolver inspects the app main executable or a direct regular DWARF entry only. It does not recurse into frameworks, search arbitrary symbol roots, or select a payload from an image name.

Each thin Mach-O slice must contain exactly one non-zero LC_UUID, and the normalized UUID is paired with the exact CPU subtype architecture. Crash Binary Images and .ips image records must provide the same identity. An executable/app image and a dSYM are complementary providers; when no executable/app is supplied, one exact dSYM may serve as the identity and debug provider. Multiple distinct providers in one role are ambiguous. Wrong UUID, wrong architecture, missing debug data, ambiguous providers, malformed layouts, and changed file identity remain typed non-success results. The payload path, device/inode when available, size, and modification time are snapshotted and revalidated before atos.

Crash locations are either absolute or image-relative. .ips image-relative offsets use the explicitly indexed image and checked base + offset; text reports map an absolute frame to exactly one Binary Images range. Preferred __TEXT VM address, runtime base, slide, and atos input remain separate values. Overflow, underflow, missing load data, and out-of-range addresses are rejected before tool invocation. atos is fixed to /usr/bin/xcrun with an argument array, a 4 KiB batch diagnostic cap, 5 seconds per batch, 30 seconds cumulative, at most 32 batches, and no invocation for known pre-resolution identity/address failures.

Post-fix verification is casebook orchestration, not a generic MCP execution surface. scripts/adaptive_verification.py defaults to quick (one baseline and one candidate, 5 seconds per attempt, 15 seconds cumulative); standard is at most two plus two at 15/60 seconds and strict is at most three plus three at 30/180 seconds. A monotonic deadline is passed into each callback, including fresh-state and cleanup operations. Automatic escalation is limited to typed timing, concurrency, state-leakage, inconsistent-observation, or known- flakiness evidence; explicit levels are recorded as policy choices.

The runner never treats an arbitrary replay manifest as identity. Reuse requires a computed executable SHA-256, Mach-O UUID/architecture, build/source, environment, target, and scenario/oracle match. A decisive candidate or guardrail regression is failed even if cleanup fails afterward. Missing, stale, contaminated, conflicting, exhausted, or non-fresh evidence without a decisive regression is inconclusive; verified requires reliable baseline, candidate thresholds, guardrails, fresh/restored/notRequired state, and cleanup.

The device adapter reports CoreDevice pairing/tunnel state and legacy xcdevice availability before any mutation. A paired CoreDevice may require the read-only lock-state probe to activate its tunnel; a successful probe, not a device name or bundle identifier, is the authorization signal. CoreDevice launch uses --terminate-existing, returns a PID only from the bounded process inventory, and CoreDevice process actions accept only positive PIDs and an allowlisted signal set. CoreDevice/legacy session cleanup owns only the adapter and explicitly selected fixture process. Legacy lifecycle and LLDB-DAP mutation require ios-deploy, an existing signed .app, the explicit device-debug grant, and the separate device-mutation grant. Neither transport loads arbitrary user scripts.

Do not use the server to access software or devices without authorization. Security findings should be recorded in the active ExecPlan and fixed with a reproducing test or a documented blocker. Release, signing, notarization, and external issue reporting require explicit authorization.