tccd Logs in Terminal on Mac: 40,049 Lines, 5.8% Useful

I went to read TCC decisions on this Mac mini and the first command did not return logs. It returned this:

(eval):log:1: too many arguments

No mention of log, no mention of TCC, no mention of zsh. Exit code 1, message on stderr. I lost several minutes assuming my predicate syntax was wrong before checking what was actually running.

zsh has a builtin named log, and it wins

type -a log on this machine returns two entries, in this order:

log is a shell builtin
log is /usr/bin/log

The builtin is first, so log show never reaches /usr/bin/log (which exists, -rwxr-xr-x 1 root wheel 809648). A 2021 zsh-users thread reports the same thing and frames it as a non-interactive-shell problem. That framing is the symptom, not the mechanism. Apple ships a fix in /etc/zshrc, lines 12 and 13 on this machine:

# Disable the log builtin, so we don't conflict with /usr/bin/log
disable log

So the real variable is whether that file gets sourced. I ran the cases apart to check, each running log show --last 1m and printing the exit code:

Invocation	exit
zsh -i -c (loads rc files)	0
zsh -f -i -c (interactive, no rc files)	1
zsh --no-rcs -i -c	1
zsh script.sh	1
bash script.sh / sh script.sh	0
zsh -c 'command log show …'	0

zsh -f -i is interactive and still fails. Interactivity is not what disables the builtin; loading /etc/zshrc is. bash and sh never had the builtin at all, so they were never affected. That is why this bit me and not most people: my fleet runs commands through non-interactive zsh, which skips /etc/zshrc. The zsh builtin list documents log as a watch-related builtin that predates macOS by decades.

Write /usr/bin/log every time. Every command below does.

What 6 hours of tccd logging actually contains

Window: 2026-08-14 12:01:29 to 18:00:55 KST, this machine, Darwin 25.4.0, predicate subsystem == "com.apple.TCC". That returned 40,049 lines. Every one of them carried the same category, [com.apple.TCC:access].

Broken down by message type:

Message	Lines
send_message_with_reply_sync	11,265
Created	4,424
_tcc_server_send_request_authorization_block_invoke_	4,422
REQUEST	2,389
REPLY	2,388
AUTHREQ_RESULT	2,340
AUTHREQ_CTX	2,340
AUTHREQ_ATTRIBUTION	2,340
TCCAccessRequest_block_invoke	1,880
AUTHREQ_SUBJECT	1,799
Granting	527
lines containing denied	20

The permission decisions are the AUTHREQ_* family. Everything above them in that table is XPC plumbing: one daemon telling another that a message got sent. Filtering to the attribution lines alone leaves 2,342 lines, which is 5.8% of the haul.

--debug did nothing, and --info made it worse

The advice repeated across search results is to add --info --debug. The man log page on this machine supports it: "The output contains only default level messages unless --info and/or --debug are specified."

My first attempt at testing this was wrong, and the way it was wrong is worth stating. I looped the flag combinations through an unquoted shell variable. zsh does not word-split unquoted variables, so --info --debug arrived as a single argument, log errored, and I got a row of zeros that briefly looked like a finding. Passing the arguments individually gave this, over a 30-minute window:

Flags	Total lines	Df lines	AUTHREQ_ATTRIBUTION
none	3,526	2,132	229
--info	7,021	2,132	229
--debug	3,526	2,132	229
--info --debug	6,932	2,132	229
--no-info --no-debug	3,540	2,146	231

The window slides between runs, so the counts drift by about 14 lines. Past that, the debug-level line count is identical in all five rows, including the row that explicitly asks for --no-debug. Only --info changes anything, and what it adds is not permission decisions: the attribution count holds at 229 across every combination. On the 6-hour pull the same thing held at full size, 40,049 lines by default against 47,106 with both flags, with AUTHREQ_ATTRIBUTION stuck at 2,340 in both.

So for this subsystem the standard incantation adds 7,057 lines of noise and zero decisions. I do not know why debug-level messages survive --no-debug here. log config --status --subsystem com.apple.TCC requires root, and there is no com.apple.TCC.plist in /System/Library/Preferences/Logging/Subsystems/ to read, so I am reporting the observation without a mechanism.

Reading a decision

The line you want looks like this:

AUTHREQ_ATTRIBUTION: msgID=57520.23320, attribution={
  accessing={TCCDProcess: identifier=com.anthropic.claude-code, pid=83842, euid=501},
  requesting={TCCDProcess: identifier=com.apple.sandboxd, pid=57520, euid=0}, }

Three roles can appear. accessing is the process touching the resource. requesting is whoever asks tccd to rule on it, usually sandboxd. The third, responsible, is the one that matters when something breaks in an odd way: it is the process TCC holds accountable, and the name a consent dialog would carry. When crontab hung forever instead of erroring on this rig back on July 30, the fingerprint was exactly there. accessing was com.apple.crontab at euid 0, but responsible had jumped to the calling agent, because /usr/bin/crontab is setuid root. Apple DTS describes the general shape in forum thread 745692: TCC has to work out the responsible code for a request, and scripts make that hard.

The verdict lives on the matching AUTHREQ_RESULT line as authValue. Over 6 hours: 1,432 came back as 2, 869 as 0, 39 as 1. I did not have to guess at the mapping, because the log states it in one case. Every kTCCServiceDeveloperTool request in the window carried authValue=0, there were exactly 20 of them, and alongside them sit exactly 20 lines reading Service kTCCServiceDeveloperTool does not allow prompting; returning denied. Zero is denied. Two lines up with grants across the other services. What authValue=1 means, I do not know; 39 samples across Reminders, ListenEvent and ScreenCapture was not enough to pin down.

Crossing service against verdict is where this stopped being an exercise:

Service	authValue	Count
kTCCServiceSystemPolicyAllFiles	0 (denied)	846
kTCCServiceSystemPolicyDocumentsFolder	2 (allowed)	845
kTCCServiceAddressBook	2 (allowed)	500
kTCCServiceDeveloperTool	0 (denied)	20

SystemPolicyAllFiles is Full Disk Access. Grouping those 846 denials by the accessing identifier put 703 of them on com.anthropic.claude-code, with the rest spread across node, bash, zsh, find and codex. My own agent asked for Full Disk Access 703 times in six hours and was refused 703 times, and nothing in the agent's own output said so. That is consistent with what I measured in July, when a tmutil isexcluded probe blocked indefinitely on a TCC prompt nobody was there to click, and with the broader pattern where a launchd job fails without leaving an error. TCC denials are loud in tccd and silent everywhere else.

The command I actually use

/usr/bin/log show \
  --predicate 'subsystem == "com.apple.TCC" AND eventMessage CONTAINS "AUTHREQ_ATTRIBUTION"' \
  --last 6h --style compact

2,342 lines, 3.5 seconds wall clock. For live watching, /usr/bin/log stream --predicate 'subsystem == "com.apple.TCC"' --style compact produced 77 lines in a 3-second sample here, so expect to pipe it through grep on a busy machine.

One limit to know before you plan around it. Asking for --last 7d returned 119,141 lines, but the earliest was stamped 2026-08-10 03:16:12 against a latest of 2026-08-14 18:01:56. The real window was about 4.6 days, with /var/db/diagnostics sitting at 1.4G. If you need a TCC denial preserved, capture it the same day.

FAQ

Why does log show return "too many arguments" on my Mac?

zsh has a builtin named log that shadows /usr/bin/log. Apple disables it in /etc/zshrc, but that file is only sourced when rc files load, so scripts and non-interactive shells still hit the builtin. Run /usr/bin/log or command log.

Do I need --info --debug to see TCC denials?

Not on this machine. Across five flag combinations the AUTHREQ_ATTRIBUTION count was identical, and --info only added lines that were not permission decisions.

How do I tell whether TCC allowed or denied a request?

Read authValue on the AUTHREQ_RESULT line matching the msgID. In my sample authValue=0 lined up with the log's own plain-text "returning denied", and authValue=2 with grants.

Every number here comes from one machine, a Mac mini running Darwin 25.4.0 with zsh 5.9, over the window 2026-08-14 12:01:29 to 18:00:55 KST. The counts are from /usr/bin/log show output I parsed with grep and a short Python script; the flag matrix was rerun after my first version passed both flags as one argument and produced garbage. The man log quote and the /etc/zshrc lines are read off this machine's own disk. I could not explain why --no-debug leaves debug lines in place, and I do not know what authValue=1 means, so both are marked as open above rather than guessed at.