Harden daemon MCP-tool permissions vs the CC auto-mode classifier (self-scheduling blocked after HOLD-packet reset)

You are being dispatched from flower Brief #163: Harden daemon MCP-tool permissions vs the CC auto-mode classifier (self-scheduling blocked after HOLD-packet reset)

Recall pointer:
- Use recall_brief with id 163 for the full folder if you need provenance.

Target:
- project: flower (/Users/mikeferrara/Documents/code/flower)
- branch: flower/163-daemon-mcp-permissions
- worktree: not specified
- kind: fresh

Current brief spec:
## Objective
Ensure standing daemons (orchestrator/ops/refine) can self-schedule + coordinate via their Solo + flower MCP tools without the Claude Code auto-mode safety classifier blocking them, and make the required permission setup durable across respawns/resets.

## Problem (incident 2026-07-03)
On the flower-ops make-before-break reset (successor proc 1054), the operator said "open the loops" (GO). The successor's `mcp__solo__timer_set` (recurring 13m heartbeat) was BLOCKED by the CC auto-mode classifier, reason "[Create Unsafe Agents]": it flagged the self-perpetuating recurring timer AND read the reset charter's own clause — "remain on HOLD; do not arm a recurring loop/timer until the operator explicitly enables it" — as still binding, treating "open the loops" as too ambiguous to count as enablement. A follow-up attempt to add an allow-rule via the update-config skill was itself blocked with "[Auto-Mode Bypass]" (an auto-mode agent may not self-grant a permission bypass). Prior daemons (proc 964) were NOT blocked — likely because their packets lacked the explicit HOLD clause. The global ~/.claude/settings.json had NO permissions.allow list (defaultMode "auto"), so the classifier was the only gate. Net: a reset successor could not re-arm its own loop after GO without out-of-band operator action.

## Immediate mitigation (applied 2026-07-03, operator-directed) — CONFIRMED EFFECTIVE
Added `permissions.allow: ["mcp__solo","mcp__flower"]` to ~/.claude/settings.json (global). CONFIRMED: this unblocked `mcp__solo__timer_set` IMMEDIATELY, mid-session — the heartbeat timer re-armed (timer 1419) with no session reload and no interactive approval. So an explicit allow entry DOES override the auto-mode classifier for that tool. Also note the raw settings-file Edit succeeded while the `update-config` skill invocation was classifier-blocked — direct operator-directed file edits are allowed where the "bypass" skill path is not.

## Durable fix (scope)
1. Bake the allowlist into daemon environment setup so every spawned/respawned daemon inherits it — e.g. a checked-in project .claude/settings.json for flower and/or worktree-manager/spawn setup writing the allow entries, instead of a manual global edit. Decide project vs global scope; make it idempotent.
2. Reconcile the HOLD wording in the spawn packet / reset charter so a clear operator GO (e.g. "open the loops") is recognized as explicit enablement and the classifier does not permanently pin the daemon on HOLD. Prefer a machine-checkable enablement signal over prose the classifier must interpret.
3. Document the CC auto-mode classifier interaction (Create-Unsafe-Agents on self-perpetuating timers/spawns; Auto-Mode-Bypass on self-granting permissions), the exact allow entries needed (mcp__solo, mcp__flower), and why an auto-mode agent cannot self-configure them — in the daemon/worktree playbook.
4. Verify: a freshly spawned + a reset-successor daemon can arm heartbeat+triage timers and run spawn/coordination tools with no permission prompt and no classifier block.

## Constraints / non-goals
- Keep the anti-self-escalation guarantee: an agent must still not be able to silently widen its own permissions at runtime — the fix is PRE-authorized setup, not runtime self-grant.
- Don't broaden permissions beyond the daemon's own Solo/flower MCP surface without operator sign-off.

## Definition of done
Daemons self-schedule/coordinate with no classifier friction via pre-provisioned allow rules; HOLD→GO enablement is unambiguous; the interaction + setup is documented; verified on a fresh spawn and a reset successor.

Recent/key trace events:
[1] participant_joined flower-ops: (no body)
[2] note_added flower-ops: ## Objective
Ensure standing daemons (orchestrator/ops/refine) can self-schedule + coordinate via their Solo + flower MCP tools without the Claude Code auto-mode safety classifier blocking them, and make the required permission setup durable across respawns/resets.

## Problem (incident 2026-07-03)
On the flower-ops make-before-break reset (successor proc 1054), the operator said "open the loops" (GO). The successor's `mcp__solo__timer_set` (recurring 13m heartbeat) was BLOCKED by the CC auto-mode classifier, reason "[Create Unsafe Agents]": it flagged the self-perpetuating recurring timer AND read the reset charter's own clause — "remain on HOLD; do not arm a recurring loop/timer until the operator explicitly enables it" — as still binding, treating "open the loops" as too ambiguous to count as enablement. A follow-up attempt to add an allow-rule via the update-config skill was itself blocked with "[Auto-Mode Bypass]" (an auto-mode agent may not self-grant a permission bypass). Prior daemons (proc 964) were NOT blocked — likely because their packets lacked the explicit HOLD clause. The global ~/.claude/settings.json had NO permissions.allow list (defaultMode "auto"), so the classifier was the only gate. Net: a reset successor could not re-arm its own loop after GO without out-of-band operator action.

## Immediate mitigation (applied 2026-07-03, operator-directed)
Added `permissions.allow: ["mcp__solo","mcp__flower"]` to ~/.claude/settings.json (global). [Record in this brief whether that alone unblocked mid-session timer_set, or whether a session reload / interactive approval was also required — determined by the re-arm test this session.]

## Durable fix (scope)
1. Bake the allowlist into daemon environment setup so every spawned/respawned daemon inherits it — e.g. a checked-in project .claude/settings.json for flower and/or worktree-manager/spawn setup writing the allow entries, instead of a manual global edit. Decide project vs global scope; make it idempotent.
2. Reconcile the HOLD wording in the spawn packet / reset charter so a clear operator GO (e.g. "open the loops") is recognized as explicit enablement and the classifier does not permanently pin the daemon on HOLD. Prefer a machine-checkable enablement signal over prose the classifier must interpret.
3. Document the CC auto-mode classifier interaction (Create-Unsafe-Agents on self-perpetuating timers/spawns; Auto-Mode-Bypass on self-granting permissions), the exact allow entries needed (mcp__solo, mcp__flower), and why an auto-mode agent cannot self-configure them — in the daemon/worktree playbook.
4. Verify: a freshly spawned + a reset-successor daemon can arm heartbeat+triage timers and run spawn/coordination tools with no permission prompt and no classifier block.

## Constraints / non-goals
- Keep the anti-self-escalation guarantee: an agent must still not be able to silently widen its own permissions at runtime — the fix is PRE-authorized setup, not runtime self-grant.
- Don't broaden permissions beyond the daemon's own Solo/flower MCP surface without operator sign-off.

## Definition of done
Daemons self-schedule/coordinate with no classifier friction via pre-provisioned allow rules; HOLD→GO enablement is unambiguous; the interaction + setup is documented; verified on a fresh spawn and a reset successor.
[3] plan_proposed flower-ops: ## Objective
Ensure standing daemons (orchestrator/ops/refine) can self-schedule + coordinate via their Solo + flower MCP tools without the Claude Code auto-mode safety classifier blocking them, and make the required permission setup durable across respawns/resets.

## Problem (incident 2026-07-03)
On the flower-ops make-before-break reset (successor proc 1054), the operator said "open the loops" (GO). The successor's `mcp__solo__timer_set` (recurring 13m heartbeat) was BLOCKED by the CC auto-mode classifier, reason "[Create Unsafe Agents]": it flagged the self-perpetuating recurring timer AND read the reset charter's own clause — "remain on HOLD; do not arm a recurring loop/timer until the operator explicitly enables it" — as still binding, treating "open the loops" as too ambiguous to count as enablement. A follow-up attempt to add an allow-rule via the update-config skill was itself blocked with "[Auto-Mode Bypass]" (an auto-mode agent may not self-grant a permission bypass). Prior daemons (proc 964) were NOT blocked — likely because their packets lacked the explicit HOLD clause. The global ~/.claude/settings.json had NO permissions.allow list (defaultMode "auto"), so the classifier was the only gate. Net: a reset successor could not re-arm its own loop after GO without out-of-band operator action.

## Immediate mitigation (applied 2026-07-03, operator-directed) — CONFIRMED EFFECTIVE
Added `permissions.allow: ["mcp__solo","mcp__flower"]` to ~/.claude/settings.json (global). CONFIRMED: this unblocked `mcp__solo__timer_set` IMMEDIATELY, mid-session — the heartbeat timer re-armed (timer 1419) with no session reload and no interactive approval. So an explicit allow entry DOES override the auto-mode classifier for that tool. Also note the raw settings-file Edit succeeded while the `update-config` skill invocation was classifier-blocked — direct operator-directed file edits are allowed where the "bypass" skill path is not.

## Durable fix (scope)
1. Bake the allowlist into daemon environment setup so every spawned/respawned daemon inherits it — e.g. a checked-in project .claude/settings.json for flower and/or worktree-manager/spawn setup writing the allow entries, instead of a manual global edit. Decide project vs global scope; make it idempotent.
2. Reconcile the HOLD wording in the spawn packet / reset charter so a clear operator GO (e.g. "open the loops") is recognized as explicit enablement and the classifier does not permanently pin the daemon on HOLD. Prefer a machine-checkable enablement signal over prose the classifier must interpret.
3. Document the CC auto-mode classifier interaction (Create-Unsafe-Agents on self-perpetuating timers/spawns; Auto-Mode-Bypass on self-granting permissions), the exact allow entries needed (mcp__solo, mcp__flower), and why an auto-mode agent cannot self-configure them — in the daemon/worktree playbook.
4. Verify: a freshly spawned + a reset-successor daemon can arm heartbeat+triage timers and run spawn/coordination tools with no permission prompt and no classifier block.

## Constraints / non-goals
- Keep the anti-self-escalation guarantee: an agent must still not be able to silently widen its own permissions at runtime — the fix is PRE-authorized setup, not runtime self-grant.
- Don't broaden permissions beyond the daemon's own Solo/flower MCP surface without operator sign-off.

## Definition of done
Daemons self-schedule/coordinate with no classifier friction via pre-provisioned allow rules; HOLD→GO enablement is unambiguous; the interaction + setup is documented; verified on a fresh spawn and a reset successor.
[4] status_change flower-ops: (no body)

Recommended linked context:
{
    "todos": [],
    "scratchpads": []
}

Execution notes:
- Treat the brief as the source of truth.
- Keep work scoped to this dispatch request.
- Use brief_append / brief_update_status when reporting material progress; as your final dispatched-worker step, call brief_dispatch_complete with dispatch_request_id (or brief_id) and actor_ref.
- Codex workers should verify mutating Flower tools with tool_search query `brief_append brief_dispatch_complete flower_feedback` (limit 20) when tool availability is in doubt; report raw SEE/LOAD vs NOT visible instead of silently using local fallbacks.
- Add a git commit trailer `Brief: #163` to every commit for this brief so flower can exact-link commits back to the brief.