Background Bash task (Supabase CLI) triggered a macOS Keychain permission prompt with no attribution or gating

What happened

During an agent session, Claude Code ran a background Bash task (a read-only CLI command: npx supabase migration list --linked). The Supabase CLI, as part of its credential lookup, attempted to read an access token from the macOS Keychain, which surfaced a system Keychain permission dialog to the user — outside any interactive context, from a task the user wasn't watching.

The command itself failed harmlessly (Access token not provided… — no token in the shell env), so nothing was read or written. But the user experienced an unexplained system-level credential-store permission prompt triggered by an unattended agent task.

Why this matters

• Third-party CLIs (Supabase, and plausibly others: gcloud, docker, etc.) reach into the OS keychain as an implementation detail of "read-only" commands. The agent has no visibility that a keychain access is about to happen, so it can't warn the user or ask first.
• When the triggering task runs in the background, the OS dialog appears with zero attribution — the user has no way to connect the prompt to the agent's action, which reads as the agent "messing with system permissions."

Suggested improvements

1. Sandbox policy: intercept or deny keychain/credential-store access from sandboxed Bash commands by default, surfacing a Claude Code permission request instead of letting the raw OS dialog appear.
2. At minimum, attribute it: if a background task's subprocess triggers an OS credential prompt, surface a notice in the session ("background task X attempted keychain access").

Environment

• Claude Code CLI on macOS (Darwin 25.5.0)
• Model: claude-fable-5
• Trigger: npx supabase migration list --linked via the Bash tool with run_in_background (moved to background after a 60s timeout)