[BUG] macOS: long-lived `claude -p` process periodically spawns a child process, triggering a recurring "would like to access data from other apps" (kTCCServiceSystemPolicyAppData) permission prompt

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Confirmed timing across two independent long-lived processes, each firing on its own ~10-minute cycle (timestamps 10, 20, and again ~21 minutes apart after an explicit Allow click — the grant did not persist to the next cycle, presumably because each cycle's child gets a fresh ephemeral PID that isn't recognized as "already decided").

What this is not

• Not related to any tool use in the conversation (Bash/osascript/AppleScript, MCP tool calls, etc.) — verified no kTCCServiceAppleEvents entries correlate with this at all.
• Not caused by anything the calling application does — a deliberately-triggered one-shot subagent spawn (Task/Agent tool) did not reproduce it either; only sustained process lifetime does.

Impact
Running claude -p as a long-lived background engine (e.g. to power a persistent multi-turn session, like a chat server keeping several ticket-scoped sessions warm) causes a recurring, unactionable macOS permission dialog with no way to durably suppress it, since the underlying decision apparently can't be cached across the periodic child-process respawn.

Ask

• What is this periodic child-process spawn for (auto-update check? telemetry/heartbeat?), and can it avoid triggering a cross-process TCC responsibility check — e.g. by not spawning a new process at all, or by having the child properly inherit/share the parent's already-consented identity so macOS doesn't need to re-evaluate it every cycle?
• Is there a supported way to disable whatever background behavior causes this for long-lived headless/service-style usage?

What Should Happen?

Confirmed timing across two independent long-lived processes, each firing on its own ~10-minute cycle (timestamps 10, 20, and again ~21 minutes apart after an explicit Allow click — the grant did not persist to the next cycle, presumably because each cycle's child gets a fresh ephemeral PID that isn't recognized as "already decided").

What this is not

• Not related to any tool use in the conversation (Bash/osascript/AppleScript, MCP tool calls, etc.) — verified no kTCCServiceAppleEvents entries correlate with this at all.
• Not caused by anything the calling application does — a deliberately-triggered one-shot subagent spawn (Task/Agent tool) did not reproduce it either; only sustained process lifetime does.

Impact
Running claude -p as a long-lived background engine (e.g. to power a persistent multi-turn session, like a chat server keeping several ticket-scoped sessions warm) causes a recurring, unactionable macOS permission dialog with no way to durably suppress it, since the underlying decision apparently can't be cached across the periodic child-process respawn.

Ask

• What is this periodic child-process spawn for (auto-update check? telemetry/heartbeat?), and can it avoid triggering a cross-process TCC responsibility check — e.g. by not spawning a new process at all, or by having the child properly inherit/share the parent's already-consented identity so macOS doesn't need to re-evaluate it every cycle?
• Is there a supported way to disable whatever background behavior causes this for long-lived headless/service-style usage?

Error Messages/Logs

Steps to Reproduce

Confirmed timing across two independent long-lived processes, each firing on its own ~10-minute cycle (timestamps 10, 20, and again ~21 minutes apart after an explicit Allow click — the grant did not persist to the next cycle, presumably because each cycle's child gets a fresh ephemeral PID that isn't recognized as "already decided").

What this is not

• Not related to any tool use in the conversation (Bash/osascript/AppleScript, MCP tool calls, etc.) — verified no kTCCServiceAppleEvents entries correlate with this at all.
• Not caused by anything the calling application does — a deliberately-triggered one-shot subagent spawn (Task/Agent tool) did not reproduce it either; only sustained process lifetime does.

Impact
Running claude -p as a long-lived background engine (e.g. to power a persistent multi-turn session, like a chat server keeping several ticket-scoped sessions warm) causes a recurring, unactionable macOS permission dialog with no way to durably suppress it, since the underlying decision apparently can't be cached across the periodic child-process respawn.

Ask

• What is this periodic child-process spawn for (auto-update check? telemetry/heartbeat?), and can it avoid triggering a cross-process TCC responsibility check — e.g. by not spawning a new process at all, or by having the child properly inherit/share the parent's already-consented identity so macOS doesn't need to re-evaluate it every cycle?
• Is there a supported way to disable whatever background behavior causes this for long-lived headless/service-style usage?

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

2.1.210

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

_No response_