Scheduled agents: async approval for permission prompts (e.g. via Slack)

Problem

Scheduled remote agents (triggers) get blocked by interactive Deny/Allow permission prompts when the repository's .claude/settings.json has commands in the "ask" list (e.g., git commit, git push).

Since remote agents run unattended on a cron schedule, there's no one to click "Allow once" — the agent just stalls. The allowed_tools field in the trigger config does not override repo-level ask permissions, and neither does switching environments.

Current behavior

1. Repo .claude/settings.json has "ask": ["Bash(git commit:*)", "Bash(git push:*)"]
2. Scheduled agent runs, writes a file, and tries to git add && git commit
3. Agent hits a blocking Deny / Allow once prompt
4. No one is there to approve it → agent stalls

Tested with:

• Granular allowed_tools patterns (e.g., Bash(git commit:*)) in trigger config — no effect
• Switching between Default and Full environments — no effect

Proposed solutions

1. Async approval via external channels (Slack, email, webhook)

When a remote agent hits a permission prompt, send an approval request to a configured channel (Slack, email, webhook). The user approves/denies from there, and the agent resumes.

2. Trigger-level permission overrides

Allow the trigger's allowed_tools to override repo-level ask permissions. This way, a scheduled agent can be explicitly granted permissions that would normally require interactive approval, without changing the repo settings that protect local interactive sessions.

3. Separate permission context for remote sessions

Support a .claude/settings.remote.json or similar mechanism that applies only to remote/scheduled sessions, so users can keep strict ask rules locally while allowing unattended execution remotely.

Workaround

Move commands from ask to allow in .claude/settings.json — but this removes the interactive confirmation for local sessions too, which is undesirable.

Context

This affects any scheduled agent that needs to perform git operations (commit, push, create PRs) in repos where those commands require interactive approval — which is a common and sensible local safety measure.