fix: the interactive cleanup costs one click per archived session, say so

Disproved live 2026-08-14 on 2.1.220, dialog on screen during a bulk sweep:
the app confirms every archive_session call with its own dialog, 'Allow once'
the only approval, regardless of permission mode or allow rules - bypass
included. The skill and paste block promised the section 5 rules made the
cleanup promptless, which was true of the lookup steps only, and a user who
believed it walked into one dialog per session with no warning. Both copies
now price it honestly, and a test bans the word promptless from either.

The archive_session allow rule stays in section 5: it costs nothing and
covered the builds where it did apply. design.md carries the same correction
uncommitted alongside the pending --no-session-persistence work, to keep this
commit off files that strand is holding.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Author: sturimcode

skills/setup-sidebar-sync/SKILL.md

@@ -79,7 +79,7 @@ Keep it to a few lines:
 
 The routine archives nothing, by design. An `archive_session` call from a scheduled run always raises a manual approval - "This tool requires explicit approval regardless of permission mode" - and no permission rule bypasses it (observed live 2026-07-30, twice: for the run's own session and for ordinary sessions alike, while `set_session_title` auto-approved in those same runs). A cleanup step inside the task would stall waiting for a person who is not watching. Re-checked 2026-08-14 on Claude Code 2.1.220 with the archive rule pre-approved in settings.json: the scheduled call still stalled.
 
-So it is something the user asks for, in any interactive desktop session, where the rules from section 5 make it promptless. Tell them that, and tell them what the session doing it has to do:
+So it is something the user asks for, in any interactive desktop session - at a price the user should hear before saying yes: one click per session archived. On current builds the app confirms every archive_session call with its own dialog, 'Allow once' the only approval, whatever the permission mode or allow rules say (seen live 2026-08-14 on 2.1.220, one dialog per session in a bulk sweep). The section 5 rules quiet the lookup steps, list_sessions and get_session; they do not quiet the archive itself. Tell them that, and tell them what the session doing it has to do:
 
 - Find prior runs by their **scheduled-task linkage**: list the app's sessions, call `get_session` on each candidate, and act only on the ones whose linkage names `session-title-sidebar-sync`.
 - **Never match on title.** claude-session-namer renames these run sessions itself, usually within a couple of replies, so a run's title says nothing about which task produced it.

src/commands.js

@@ -617,7 +617,7 @@ const SIDEBAR_PASTE_BLOCK = `Set up the claude-session-namer sidebar sync. Using
 
 ${SIDEBAR_TASK_PROMPT}
 
-Then offer to pre-approve the routine's permissions durably, and with my consent add these to the permissions.allow array in ~/.claude/settings.json (read the file first, merge, never replace other entries): "Bash(claude-session-namer sync-plan:*)", "Bash(claude-session-namer sweep-done:*)", "mcp__ccd_session_mgmt__set_session_title", "mcp__ccd_session_mgmt__list_sessions", "mcp__ccd_session_mgmt__get_session", "mcp__ccd_session_mgmt__archive_session". Run-time prompt approvals do not reliably persist for the app's own tools. After writing, read the file back and check every rule just listed is present, naming any that is missing rather than assuming the write took. Also tell me the permission mode is a separate setting the allow rules do not cover - the mode picked in a session falls back every fresh session unless permissions.defaultMode is set in the same file - and offer to set it, asking me which mode rather than picking one. Then tell me how old run sessions get cleared, because the routine cannot do it itself: the app requires manual approval for archive_session in a scheduled run whatever permission rules are set, so I ask an interactive desktop session to archive prior runs of the \`${SIDEBAR_TASK_ID}\` task instead. Whoever does that works from the scheduled-task linkage - list the sessions, call get_session on each candidate, archive only the ones whose linkage names that task id. Never match on title, since claude-session-namer renames these run sessions itself; never the current session; never a session whose linkage could not be read. Finish by offering to prove the path once now, by running the task's steps yourself in this session: \`claude-session-namer sync-plan\`, then the set_session_title call for each line it prints, then \`claude-session-namer sweep-done\`. Never test it by scheduling the task to fire: a one-time \`fireAt\` run clears the cron schedule and the task disables itself after firing, which leaves the hourly sync dead with nothing said.
+Then offer to pre-approve the routine's permissions durably, and with my consent add these to the permissions.allow array in ~/.claude/settings.json (read the file first, merge, never replace other entries): "Bash(claude-session-namer sync-plan:*)", "Bash(claude-session-namer sweep-done:*)", "mcp__ccd_session_mgmt__set_session_title", "mcp__ccd_session_mgmt__list_sessions", "mcp__ccd_session_mgmt__get_session", "mcp__ccd_session_mgmt__archive_session". Run-time prompt approvals do not reliably persist for the app's own tools. After writing, read the file back and check every rule just listed is present, naming any that is missing rather than assuming the write took. Also tell me the permission mode is a separate setting the allow rules do not cover - the mode picked in a session falls back every fresh session unless permissions.defaultMode is set in the same file - and offer to set it, asking me which mode rather than picking one. Then tell me how old run sessions get cleared, because the routine cannot do it itself: the app requires manual approval for archive_session in a scheduled run whatever permission rules are set, so I ask an interactive desktop session to archive prior runs of the \`${SIDEBAR_TASK_ID}\` task instead. Warn me before starting that the app raises one confirmation dialog per archived session regardless of permission mode or allow rules, so a bulk cleanup is a clicking exercise and should be sized to my patience. Whoever does that works from the scheduled-task linkage - list the sessions, call get_session on each candidate, archive only the ones whose linkage names that task id. Never match on title, since claude-session-namer renames these run sessions itself; never the current session; never a session whose linkage could not be read. Finish by offering to prove the path once now, by running the task's steps yourself in this session: \`claude-session-namer sync-plan\`, then the set_session_title call for each line it prints, then \`claude-session-namer sweep-done\`. Never test it by scheduling the task to fire: a one-time \`fireAt\` run clears the cron schedule and the task disables itself after firing, which leaves the hourly sync dead with nothing said.
 `;
 
 // Printed by install only when the user says they use the desktop app.

test/sidebar.test.js

@@ -110,7 +110,7 @@ test('the skill hands the cleanup to an interactive session, matched by linkage
 });
 
 // The three session tools stay pre-approved even though the routine no longer calls any of them:
-// they are exactly what makes the user's own cleanup promptless in an interactive session, which is
+// they keep the lookup half of the user's own cleanup quiet in an interactive session, which is
 // the only place it can happen.
 test('both setup paths still pre-approve the tools the interactive cleanup needs', () => {
   for (const [name, text] of [['skill', skill()], ['paste block', SIDEBAR_PASTE_BLOCK]]) {
@@ -149,6 +149,21 @@ test('both setup paths name the permission mode as a separate setting and leave
   assert.match(SIDEBAR_PASTE_BLOCK, /asking me which mode/, 'the paste path asks too');
 });
 
+// Disproved live 2026-08-14 on 2.1.220, dialog on screen: the app confirms EVERY archive_session
+// call with its own dialog - "Allow once" is the only approval - regardless of permission mode,
+// allow rules, or even bypass. The section 5 rules quiet the two lookup steps and nothing else. So
+// the honest promise is one click per archived session, both copies of the instructions have to
+// make it, and the word "promptless" cannot appear anywhere a user would read it as a sweep that
+// runs itself.
+test('both setup paths price the cleanup honestly: one confirmation per archived session', () => {
+  assert.match(skill(), /one click per session archived/);
+  assert.match(skill(), /do not quiet the archive itself/);
+  assert.match(SIDEBAR_PASTE_BLOCK, /one confirmation dialog per archived session/);
+  for (const [name, text] of [['skill', skill()], ['paste block', SIDEBAR_PASTE_BLOCK]]) {
+    assert.ok(!/promptless/.test(text), `${name}: the promptless claim died 2026-08-14`);
+  }
+});
+
 // The routine's run sessions are sessions like any other, so the Stop hook titles them - which is
 // both a wasted model call and, before this, the thing that broke the cleanup step above. The tool
 // recognizes them by the prompt's opening line, so that line cannot be a copy: the template is built