"Always allow" permission decision does not persist across scheduled/unattended session runs

Description

Clicking "Always allow" on a permission prompt (Bash, Edit, MCP tool call, etc.) during a scheduled/unattended session run does not appear to persist the decision to any project settings file, so the identical prompt reappears on the next scheduled run of the same task — even though the UI implies the choice is permanent.

Setup

• Desktop app, a project directory with several recurring scheduled tasks (mcp__scheduled-tasks__*) that run unattended on a cron-like schedule, with no user present to approve prompts.
• Project has both .claude/settings.json and .claude/settings.local.json with an existing permissions.allow list.

Steps to reproduce

1. Have a scheduled task configured to run headlessly (observed launching as claude --permission-mode default --permission-prompt-tool stdio).
2. Let it hit an action not covered by the existing allowlist (in our case, an Edit to a file that should have matched an existing glob rule, e.g. Edit(.../dashboard/**) not matching .../dashboard/index.html) — the run stalls in "Needs input" with no user present.
3. Open the app later and manually approve the pending prompt via "Always allow" (UI indicated it would add rule(s)).
4. Inspect .claude/settings.json, .claude/settings.local.json, and the global ~/.claude/settings.json immediately after — none contain a new rule reflecting the approval.
5. The next time the same scheduled task runs and reaches the same action, it stalls again in "Needs input," requiring another manual approval.

Expected behavior

"Always allow" should write a persistent rule to a settings file (presumably .claude/settings.local.json) so that subsequent runs — especially unattended/scheduled ones with no user present — do not hit the same prompt again.

Actual behavior

The approval appears to only apply to the in-progress run. No settings file is updated. Every subsequent scheduled run of the same task starts "blind" to all prior approvals, defeating the purpose of "Always allow" for unattended workflows. This has been consistently reproduced across many days of scheduled runs (multiple daily trading-agent sessions), not a one-off.

Impact

For any workflow relying on unattended/scheduled Claude Code sessions (cron-style automation with no user present to approve prompts), this makes "Always allow" effectively useless — every new permission gap requires either (a) a human manually re-approving on every single run indefinitely, or (b) hand-editing .claude/settings.json directly as a workaround (which does work reliably, confirming the settings file mechanism itself is fine — it's specifically the "Always allow" button's write-back that appears broken for this execution mode).

Environment

• Claude Code desktop app
• Scheduled sessions launched via the app's own scheduled-tasks mechanism (--permission-mode default --permission-prompt-tool stdio)