diff --git a/CHANGELOG.md b/CHANGELOG.md
index 2a7a578f3..62df3e95a 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -13,6 +13,16 @@ Compatibility is documented in release notes, not encoded in the version string.
 
 ### Added
 
+- A tokenless `queue_start` now files a **start request** the operator confirms
+  in the BLUESKY queue panel, instead of dead-ending in a refusal. Deployed
+  web terminals never hold the scan launch token by design; the agent stages
+  and queues, the request appears in the queue panel beside the queue it would
+  drain, and the human's *Confirm start* click — the panel's own token-gated
+  start — is what arms it. Dismissing the request is always available and
+  starts nothing. Skill and error-message guidance across the scan stack now
+  explains this posture so agents hand the start to the human instead of
+  chasing the token in configuration.
+
 - An archiver read that comes back empty now says why: the response carries a
   coverage verdict — the window predates or postdates the archive, the channel
   was never recorded, or the window holds a genuine gap — with the archive's
@@ -156,6 +166,13 @@ Compatibility is documented in release notes, not encoded in the version string.
 
 ### Changed
 
+- Deployed agents can no longer reconfigure their own harness: the Claude Code
+  CLI's bundled harness-configuration skills (`update-config`,
+  `keybindings-help`, `fewer-permission-prompts`) are switched off in every
+  rendered project, and the `setup-mode` skill (which can patch config.yml)
+  left the operator preset's default roster — it stays in the artifact catalog
+  for admin profiles to opt into. Rebuilt control-assistant projects will
+  report preset staleness once; that is the intended signal.
 - **Log out** moved into the web terminal's display menu, alongside
   **Settings** — the two now sit side by side under a line naming the signed-in
   user. The separate user chip in the header is gone, leaving search and the
diff --git a/docs/source/how-to/bluesky/queue.rst b/docs/source/how-to/bluesky/queue.rst
index cc3d1fd3a..c5b4991c2 100644
--- a/docs/source/how-to/bluesky/queue.rst
+++ b/docs/source/how-to/bluesky/queue.rst
@@ -66,12 +66,13 @@ One queue, three ways to drive it
 
       .. code-block:: text
 
-         POST /queue/items        add the current draft revision
-         POST /queue/start        start draining (needs the launch token)
-         POST /queue/stop         stop after the running item
-         POST /queue/abort        abort the running plan — never gated
-         GET  /queue              what is queued and running
-         GET  /runs               recent runs; /runs/<id>/data for the numbers
+         POST /queue/items          add the current draft revision
+         POST /queue/start          start draining (needs the launch token)
+         POST /queue/start-request  ask a token holder to start — arms nothing
+         POST /queue/stop           stop after the running item
+         POST /queue/abort          abort the running plan — never gated
+         GET  /queue                what is queued and running
+         GET  /runs                 recent runs; /runs/<id>/data for the numbers
 
       Every refusal comes back with a ``detail`` object of the form
       ``{"code": ..., "detail": ...}`` — a stable code for software to
@@ -115,6 +116,9 @@ quirks worth knowing:
         - The launch token — this hands work straight to a moving machine.
       * - Start the queue
         - The launch token.
+      * - Ask for a start (file a start request)
+        - Nothing — the request arms nothing. Confirming it *is* the
+          token-gated start, done from the queue panel.
       * - Stop the queue / abort the running plan
         - Nothing. Ever. Anywhere.
       * - Withdraw a pending stop
@@ -126,6 +130,14 @@ quirks worth knowing:
    anything, even on an idle queue. Its halts and its read tools are never
    taken away.
 
+   In a deployed control room the agent's environment never holds the launch
+   token at all — the token lives with the operator panels. The agent's
+   ``queue_start`` then files a **start request**: it appears in the BLUESKY
+   queue panel beside the queue it would drain, with *Confirm start* and
+   *Dismiss* controls. Confirming fires the panel's own token-carrying start;
+   dismissing starts nothing. Either way, the human's click is the arming
+   decision.
+
 .. dropdown:: When something is refused
    :color: info
    :icon: alert
@@ -138,7 +150,13 @@ quirks worth knowing:
       for a repeat.
 
    ``launch_token_required``
-      The operation was armed and the deployment is not. Nothing was started.
+      The operation was armed and the caller held no valid token. Nothing was
+      started. (An agent asking for a plain start never hits this — it files a
+      start request for the panel instead.)
+
+   ``queue_empty``
+      A start was requested with nothing queued, so there was nothing a
+      confirmation could run. Stage and add a plan first.
 
    ``browse_only_connector``
       This deployment cannot execute scans at all — it is pointed at the
diff --git a/docs/source/how-to/bluesky/run-first-scan.rst b/docs/source/how-to/bluesky/run-first-scan.rst
index f008a023c..dad3c97f1 100644
--- a/docs/source/how-to/bluesky/run-first-scan.rst
+++ b/docs/source/how-to/bluesky/run-first-scan.rst
@@ -108,8 +108,10 @@ token, no switch can disable them:
      process with its own copy of the devices. That is why the queue survives
      restarts of everything around it.
    - **Start queue** is checked against a **launch token** the deployment
-     holds. For the agent, starting is additionally switched off entirely
-     whenever the project's control-system writes are disabled.
+     holds. In deployed control rooms the agent never holds it — asking the
+     agent to start a scan gets you a **start request** to confirm in the
+     queue panel. For the agent, starting is additionally switched off
+     entirely whenever the project's control-system writes are disabled.
 
 .. dropdown:: First-run hiccups
    :color: info
diff --git a/src/osprey/cli/build_injectors.py b/src/osprey/cli/build_injectors.py
index c43d3f909..1469d01e5 100644
--- a/src/osprey/cli/build_injectors.py
+++ b/src/osprey/cli/build_injectors.py
@@ -519,7 +519,9 @@ def _inject_bluesky(bluesky: BlueskyConfig, project_path: Path) -> None:
     logger.info("  ✓ Injected Bluesky scan bridge (port %d)", bluesky.port)
     logger.info(
         "    Token:      `osprey deploy up` writes BLUESKY_LAUNCH_TOKEN to .env; "
-        "the `bluesky` MCP server's queue tools read it automatically."
+        "a host-run agent's queue tools read it automatically. Deployed web "
+        "terminals never receive it — their agents file a start request the "
+        "operator confirms in the BLUESKY queue panel."
     )
     logger.info(
         "    Images:     `osprey deploy up` builds the bluesky-bridge image locally "
diff --git a/src/osprey/deployment/web_terminals/env_production.py b/src/osprey/deployment/web_terminals/env_production.py
index 6a6600fda..d2ca8c30a 100644
--- a/src/osprey/deployment/web_terminals/env_production.py
+++ b/src/osprey/deployment/web_terminals/env_production.py
@@ -185,10 +185,16 @@ def _build_env_production_subset(
     :mod:`osprey.deployment.container_lifecycle`, minted per deploy under
     those fixed names). Neither kind is anything a web terminal presents to
     anyone: the containers that need a service token read the deploy ``.env``
-    the main compose file hands them, and nothing in a web terminal reads one
-    at all. This is the security spec for this function: a var absent from the
-    enumerated list above can never appear in the returned dict, regardless of
-    what the input ``.env`` contains.
+    the main compose file hands them. The one web-terminal consumer that
+    WOULD read a service token if present — the bluesky MCP server's
+    ``${BLUESKY_LAUNCH_TOKEN:-}`` — is tokenless here on purpose: an agent
+    container must never hold a write-arming bearer credential (any Bash or
+    Python it runs could read it and arm the queue with no approval), so its
+    ``queue_start`` files a panel start request and the operator's panels
+    sidecar, which does receive the token, answers it. This is the security
+    spec for this function: a var absent from the enumerated list above can
+    never appear in the returned dict, regardless of what the input ``.env``
+    contains.
 
     :param config: Raw deploy config (facility fields merged in — see
         ``modules.web_terminals.image_source`` in :func:`ensure_env_production`).
diff --git a/src/osprey/interfaces/bluesky_panels/panels/bluesky/index.html b/src/osprey/interfaces/bluesky_panels/panels/bluesky/index.html
index 8e20551ee..60c4652aa 100644
--- a/src/osprey/interfaces/bluesky_panels/panels/bluesky/index.html
+++ b/src/osprey/interfaces/bluesky_panels/panels/bluesky/index.html
@@ -241,6 +241,22 @@ <h2>Queue</h2>
         <button type="button" id="start-btn" class="btn" disabled>Start queue</button>
       </div>
 
+      <!-- A pending start request: the agent (which never holds the launch
+           token in a deployed terminal) asked for a start, and THIS panel is
+           where a human answers. Confirm fires the same token-carrying
+           POST /queue/start as the Start button above; Dismiss withdraws the
+           request and starts nothing. Hidden unless the status summary
+           carries a `start_request` record (queue-view.js renders it). -->
+      <div id="start-request-card" class="start-request" hidden>
+        <p id="start-request-text" class="start-request-text"></p>
+        <div class="start-request-actions">
+          <button type="button" id="confirm-start-btn" class="btn confirm" disabled>
+            Confirm start &mdash; queue drains toward hardware
+          </button>
+          <button type="button" id="dismiss-request-btn" class="btn">Dismiss request</button>
+        </div>
+      </div>
+
       <div id="running-card" class="running" hidden>
         <div class="running-head">
           <span class="running-kicker">running</span>
diff --git a/src/osprey/interfaces/bluesky_panels/panels/bluesky/panel.css b/src/osprey/interfaces/bluesky_panels/panels/bluesky/panel.css
index f5bd42472..f37b810fe 100644
--- a/src/osprey/interfaces/bluesky_panels/panels/bluesky/panel.css
+++ b/src/osprey/interfaces/bluesky_panels/panels/bluesky/panel.css
@@ -1166,6 +1166,27 @@ code {
   margin-bottom: 12px;
   background: var(--accent-tint-06);
 }
+
+/* A pending start request: the one card on this panel that asks the operator
+   for a decision, so it wears the caution tint (same vocabulary as
+   .btn.confirm — armed-and-consequential), never the accent or success one. */
+.start-request {
+  border: 1px solid var(--color-accent-secondary);
+  border-radius: 6px;
+  padding: 10px 12px;
+  margin-bottom: 12px;
+  background: var(--accent-secondary-tint-08);
+}
+.start-request-text {
+  margin: 0 0 8px;
+  font-size: 12.5px;
+  color: var(--text-primary);
+}
+.start-request-actions {
+  display: flex;
+  gap: 8px;
+  flex-wrap: wrap;
+}
 .running.selected { border-color: var(--color-accent-light); }
 
 .running-head {
diff --git a/src/osprey/interfaces/bluesky_panels/panels/bluesky/queue-client.js b/src/osprey/interfaces/bluesky_panels/panels/bluesky/queue-client.js
index 3fb423b2d..dcfc04e10 100644
--- a/src/osprey/interfaces/bluesky_panels/panels/bluesky/queue-client.js
+++ b/src/osprey/interfaces/bluesky_panels/panels/bluesky/queue-client.js
@@ -18,6 +18,9 @@
  *   items_in_queue, items_in_history, running_item_uid, plan_queue_uid,
  *   plan_history_uid, queue_stop_pending, queue_autostart_enabled, ...}`, or
  *   `{available: false, reason}` when the manager could not be read at all.
+ *   Either shape may carry `start_request` — the bridge-local record of a
+ *   tokenless caller (the agent) asking a token holder (this panel) to start
+ *   the queue; see `startRequest` / `describeStartRequest`.
  * - `items` are the manager's own item documents (`item_uid`, `name`,
  *   `kwargs`, `meta.osprey_run_id`); the running item may carry `progress`.
  *
@@ -238,6 +241,65 @@ export function queueControls(state) {
   return { start, stop };
 }
 
+// The confirm control on a pending start request. This button IS the arming
+// action — the sidecar attaches the launch token the agent never holds — so
+// its label says what confirming does, not who asked.
+export const CONFIRM_START_LABEL = 'Confirm start — queue drains toward hardware';
+export const DISMISS_START_REQUEST_LABEL = 'Dismiss request';
+
+/**
+ * The pending start request riding the status summary, or null.
+ *
+ * The record is bridge-local state (`queue.py`'s `_start_request`): an agent
+ * without the launch token filed it, and the ONLY thing that honours it is a
+ * human clicking the token-holding confirm — this accessor never decides
+ * anything, it only says whether there is something to render.
+ *
+ * @param {QueueState} state
+ * @returns {Record<string, any>|null}
+ */
+export function startRequest(state) {
+  const record = state.status && state.status.start_request;
+  return record && typeof record === 'object' ? /** @type {Record<string, any>} */ (record) : null;
+}
+
+/**
+ * The pending start request's operator-facing sentence.
+ *
+ * Names who asked, how much would run, and when — the three things an
+ * operator weighs before confirming. The item count is the count AT FILING
+ * time; the queue list right next to this card is the live truth, which is
+ * why the sentence points at it rather than restating it.
+ *
+ * @param {Record<string, any>} record
+ * @returns {string}
+ */
+export function describeStartRequest(record) {
+  const by = typeof record.requested_by === 'string' && record.requested_by ? record.requested_by : 'agent';
+  const count = Number.isInteger(record.items_in_queue)
+    ? `${record.items_in_queue} item${record.items_in_queue === 1 ? '' : 's'} at the time`
+    : 'the queued items';
+  const at = formatRequestedAt(record.requested_at);
+  return (
+    `The ${by} asks to start the queue (${count}${at ? `, requested ${at}` : ''}). ` +
+    'Confirming runs the queue exactly as listed below.'
+  );
+}
+
+/**
+ * `requested_at` as a short local time, or null when unparseable — the
+ * sentence simply omits what it cannot state truthfully.
+ *
+ * @param {unknown} iso
+ * @returns {string|null}
+ */
+function formatRequestedAt(iso) {
+  if (typeof iso !== 'string' || !iso) return null;
+  const parsed = new Date(iso);
+  if (Number.isNaN(parsed.getTime())) return null;
+  return parsed.toLocaleTimeString([], { hour: '2-digit', minute: '2-digit' });
+}
+
 /**
  * The stop button's label, across the plain stop and the two-step withdrawal.
  *
diff --git a/src/osprey/interfaces/bluesky_panels/panels/bluesky/queue-view.js b/src/osprey/interfaces/bluesky_panels/panels/bluesky/queue-view.js
index 984b4218e..248a00840 100644
--- a/src/osprey/interfaces/bluesky_panels/panels/bluesky/queue-view.js
+++ b/src/osprey/interfaces/bluesky_panels/panels/bluesky/queue-view.js
@@ -47,6 +47,7 @@ import {
   createQueueStream,
   describeProgress,
   describeQueueStatus,
+  describeStartRequest,
   historyChanged,
   historyEmptyState,
   historyRecords,
@@ -58,6 +59,7 @@ import {
   queueEmptyState,
   reduceQueueFrame,
   refusalTone,
+  startRequest,
   stopButtonClass,
   stopButtonLabel,
   writeOutcomeTone,
@@ -104,6 +106,10 @@ export function createQueueView({ root, api, onSelectRun }) {
   const queueNote = byId('queue-note');
   const queueBanner = byId('queue-banner');
   const startBtn = /** @type {HTMLButtonElement} */ (byId('start-btn'));
+  const startRequestCard = byId('start-request-card');
+  const startRequestText = byId('start-request-text');
+  const confirmStartBtn = /** @type {HTMLButtonElement} */ (byId('confirm-start-btn'));
+  const dismissRequestBtn = /** @type {HTMLButtonElement} */ (byId('dismiss-request-btn'));
   const stopBtn = /** @type {HTMLButtonElement} */ (byId('stop-btn'));
   const stopNote = byId('stop-note');
   const abortBtn = /** @type {HTMLButtonElement} */ (byId('abort-btn'));
@@ -271,6 +277,18 @@ export function createQueueView({ root, api, onSelectRun }) {
     startBtn.disabled = controls.start.disabled;
     startBtn.title = controls.start.reason || '';
 
+    // The pending start request, when the summary carries one. Confirm is the
+    // SAME arming action as the Start button — the sidecar attaches the launch
+    // token the requester never held — so it shares Start's usability gate and
+    // its reason tooltip. Dismiss is never gated: declining is always safe.
+    const request = startRequest(queue);
+    startRequestCard.hidden = request === null;
+    if (request !== null) {
+      startRequestText.textContent = describeStartRequest(request);
+      confirmStartBtn.disabled = controls.start.disabled;
+      confirmStartBtn.title = controls.start.reason || '';
+    }
+
     // The stop button is never disabled — see `queueControls`. Whatever this
     // panel believes about the manager is a tooltip, not a gate.
     stopBtn.textContent = stopButtonLabel(controls.stop, stopConfirmArmed);
@@ -560,6 +578,31 @@ export function createQueueView({ root, api, onSelectRun }) {
     );
   });
 
+  // Confirming a start request fires the same token-carrying start as the
+  // Start button — the bridge clears the request record on a successful
+  // start, and the next SSE frame hides this card. One click, like Start:
+  // the human reading this card IS the deliberation the flow exists for.
+  confirmStartBtn.addEventListener('click', () => {
+    if (confirmStartBtn.disabled) return;
+    void queueWrite(
+      'POST',
+      '/queue/start',
+      {},
+      'Start confirmed — the queue is now draining toward hardware.',
+      writeOutcomeTone(true)
+    );
+  });
+
+  dismissRequestBtn.addEventListener('click', () => {
+    void queueWrite(
+      'DELETE',
+      '/queue/start-request',
+      undefined,
+      'Start request dismissed — nothing was started.',
+      writeOutcomeTone(false)
+    );
+  });
+
   // Two-step ONLY on the withdrawal branch, matching the Plans view's
   // Add-to-queue and discard-draft buttons. A plain stop fires on the first
   // click: friction in front of a halt is friction in exactly the wrong place.
diff --git a/src/osprey/interfaces/bluesky_panels/queue_relay.py b/src/osprey/interfaces/bluesky_panels/queue_relay.py
index e60ea0b0e..b6f39a6bd 100644
--- a/src/osprey/interfaces/bluesky_panels/queue_relay.py
+++ b/src/osprey/interfaces/bluesky_panels/queue_relay.py
@@ -13,6 +13,8 @@
 - ``POST /queue/items/{uid}/move`` -> reorder one queued item
 - ``DELETE /queue/items/{uid}`` -> drop one queued item
 - ``POST /queue/start`` -> start draining the queue
+- ``POST /queue/start-request`` -> file the tokenless "please start" record
+- ``DELETE /queue/start-request`` -> dismiss a pending start request
 - ``POST /queue/stop`` -> stop after the running item (``cancel: true`` withdraws)
 - ``POST /queue/abort`` -> abort the plan already in motion
 - ``GET /queue/events`` -> the queue's Server-Sent-Events stream
@@ -247,6 +249,30 @@ async def start_queue(request: Request) -> JSONResponse:
     return await _forward_write(request, "POST", "/queue/start")
 
 
+@router.post("/queue/start-request")
+async def request_queue_start(request: Request) -> JSONResponse:
+    """Relay the filing of a start request — the tokenless "please start" record.
+
+    Exists on the panel surface for symmetry and testing; the usual FILER is
+    the agent's MCP server talking to the bridge directly, and the usual
+    CONFIRMER is this sidecar's own ``POST /queue/start``, whose launch token
+    is the entire point of the flow. The resolved token rides along like every
+    other queue write (module docstring) and the bridge ignores it — the
+    request route arms nothing for anyone.
+    """
+    return await _forward_write(request, "POST", "/queue/start-request")
+
+
+@router.delete("/queue/start-request")
+async def dismiss_queue_start_request(request: Request) -> JSONResponse:
+    """Relay the dismissal of a pending start request — the panel's Dismiss control.
+
+    Ungated at the bridge (declining to start is the safe direction), so the
+    dismissal always answers, token or no token.
+    """
+    return await _forward_write(request, "DELETE", "/queue/start-request")
+
+
 @router.post("/queue/stop")
 async def stop_queue(request: Request) -> JSONResponse:
     """Relay a queue stop, including the token-gated ``cancel: true`` withdrawal.
diff --git a/src/osprey/mcp_server/bluesky/tools/queue.py b/src/osprey/mcp_server/bluesky/tools/queue.py
index c6773e7e0..10e0903de 100644
--- a/src/osprey/mcp_server/bluesky/tools/queue.py
+++ b/src/osprey/mcp_server/bluesky/tools/queue.py
@@ -93,8 +93,18 @@
 # the tool's own generic hints — an unknown code is relayed, never dropped.
 _REFUSAL_HINTS: dict[str, list[str]] = {
     "launch_token_required": [
-        "This operation arms hardware motion and needs the bridge's launch token.",
-        "If the deployment has no BLUESKY_LAUNCH_TOKEN configured, the operator must set one.",
+        "This operation arms hardware motion and needs the bridge's launch token, "
+        "which this agent does not hold — in deployed control rooms the token stays "
+        "with the operator's BLUESKY queue panel, by design.",
+        "Hand the action to the operator: arming is done from the queue panel by a "
+        "human. Never edit config.yml, .env, or settings to obtain a token.",
+        "Only if this deployment has no token configured ANYWHERE (details say so) "
+        "does an operator need to set one — that is operator work, not yours.",
+    ],
+    "queue_empty": [
+        "The queue holds no items, so there is nothing a start could run.",
+        "Stage the plan with set_draft and add it with queue_add first, then ask "
+        "for the start again.",
     ],
     "stale_draft_revision": [
         "The draft changed after you pinned this revision; re-read it with get_draft "
@@ -223,14 +233,26 @@ def _refuse_unarmed(tool: str) -> NoReturn:
 
     Uses the bridge's own ``launch_token_required`` code so the agent branches
     on one name whether the missing token is caught here or at the bridge.
+
+    The wording is posture-aware, not accusatory: in deployed control rooms
+    the agent's environment holds no launch token BY DESIGN — the token lives
+    with the operator's queue panel, and only a human arms from there. So the
+    suggestion sends the agent to the human, never to config surgery
+    (``queue_start`` itself no longer comes here at all — tokenless, it files
+    a start request for the panel instead).
     """
     return make_error(
         "launch_token_required",
-        f"This Bluesky MCP server has no BLUESKY_LAUNCH_TOKEN configured — "
-        f"{tool} is refused client-side before contacting the bridge.",
+        f"This Bluesky MCP server holds no launch token, so {tool} is refused "
+        f"client-side before contacting the bridge. In deployed control rooms this "
+        f"is the intended posture, not a misconfiguration: the launch token stays "
+        f"with the operator's BLUESKY queue panel, and arming decisions are made "
+        f"there by a human.",
         [
-            "Set BLUESKY_LAUNCH_TOKEN (or bluesky.launch_token in config.yml) "
-            "for this bridge instance."
+            f"Ask the operator to perform this from the BLUESKY queue panel — "
+            f"{tool} is an arming action reserved for the launch-token holder.",
+            "Do not edit config.yml or environment files to obtain a token; the "
+            "agent's environment is tokenless by design in deployed terminals.",
         ],
         details={"code": "launch_token_required"},
     )
@@ -346,8 +368,11 @@ async def queue_list() -> str:
         ``status`` carries ``available`` (false when the manager could not be
         read at all, with ``reason``), ``manager_state``,
         ``worker_environment_exists``, ``items_in_queue``, ``items_in_history``,
-        ``running_item_uid``, ``queue_stop_pending`` and
-        ``queue_autostart_enabled``. A ``manager_state`` of ``executing_queue``,
+        ``running_item_uid``, ``queue_stop_pending``,
+        ``queue_autostart_enabled`` and ``start_request`` (the pending
+        panel start request a tokenless queue_start filed, or null — non-null
+        means the operator has not confirmed or dismissed it yet). A
+        ``manager_state`` of ``executing_queue``,
         ``starting_queue``, ``executing_task`` or ``paused`` means the queue is
         already draining toward hardware — adding to it then is an armed
         operation.
@@ -413,10 +438,13 @@ async def queue_add(draft_revision: int) -> str:
     Refusals (nothing is queued, and the pinned revision stays usable):
         - launch_token_required: the queue is already draining and this add
           needed the launch token. ``details.manager_state`` names the state
-          that made it armed. Either the deployment has no token, or this
-          server withheld it because writes are disabled — the suggestions say
-          which, and neither is agent-recoverable; the operator must enable
-          writes or configure the token. If ``details.item_left_behind`` is
+          that made it armed. Either this server holds no token (in deployed
+          terminals that is the intended posture — the token lives with the
+          operator's queue panel, so hand the add to the human there), or this
+          server withheld it because writes are disabled (then enabling
+          writes, an operator action, is what unblocks it) — the suggestions
+          say which. Neither is agent-recoverable, and neither is a config
+          edit for you to attempt. If ``details.item_left_behind`` is
           true, an item could NOT be withdrawn and is sitting in an armed queue
           — ``details.item_uid`` names it and a human must deal with it.
         - stale_draft_revision: the draft changed after you pinned it. Re-read
@@ -498,24 +526,43 @@ async def queue_start() -> str:
     every pending item, in order, not just the one you added — so read
     queue_list first and be sure the whole queue is what should run.
 
-    Two local gates pass before any network call: this deployment's
-    ``control_system.writes_enabled`` must re-read true (fresh every call,
-    never cached, so a hook-bypassed invocation holding a valid token is still
-    refused while writes are off), and this server must hold a launch token.
-    The bridge re-verifies the token, re-checks every queued session plan's
-    validation, and opens the worker environment if needed. The human also sees
-    an approval prompt for the start.
+    This tool behaves differently depending on where the launch token lives,
+    and BOTH outcomes are success paths — know which deployment you are in:
+
+    - **This server holds the launch token** (typically a host-run dev
+      session): the start goes to the bridge directly, behind your approval
+      prompt. ``control_system.writes_enabled`` is re-read fresh first — never
+      cached — so a hook-bypassed invocation holding a valid token is still
+      refused while writes are off. The bridge re-verifies the token,
+      re-checks every queued session plan's validation, and opens the worker
+      environment if needed. Returns ``{"started": true, "msg"}``.
+    - **This server holds no token** (every deployed web terminal — the token
+      stays with the operator's BLUESKY queue panel, by design, and no config
+      change from here can obtain it): the call files a START REQUEST instead.
+      The request shows up in the human's queue panel, right next to the queue
+      it would drain, with a Confirm control only the panel (the token holder)
+      can honour. Returns ``{"started": false, "start_request": {...},
+      "message"}`` — tell the human their confirmation is waiting in the
+      queue panel, then watch queue_status/queue_list for the start. Refiling
+      replaces the pending request; the human can also dismiss it.
 
     Returns:
-        JSON ``{"started": true, "msg"}``. The queue then drains
-        asynchronously — poll queue_list for progress and get_run_data for the
-        running item's data.
-
-    Refusals (nothing started):
-        - writes_disabled: writes are off in this deployment. Not
-          agent-recoverable; the operator must enable writes.
-        - launch_token_required: no launch token here or at the bridge, or the
-          two do not match. Not agent-recoverable; contact the operator.
+        JSON ``{"started": true, "msg"}`` when this server holds the token and
+        the bridge accepted the start — the queue then drains asynchronously
+        (poll queue_list for progress and get_run_data for the running item's
+        data). JSON ``{"started": false, "start_request", "message"}`` when
+        the start was handed to the operator's queue panel to confirm.
+
+    Refusals (nothing started, no request filed):
+        - writes_disabled: writes are off in this deployment. Refused before
+          a direct start AND before filing a request — a confirmable request
+          must not exist while the kill switch is off. Not agent-recoverable;
+          the operator must enable writes.
+        - launch_token_required: the bridge rejected this server's token (the
+          two do not match), or the bridge itself has no token configured.
+          Not agent-recoverable; contact the operator.
+        - queue_empty (tokenless path): the queue holds no items, so there is
+          nothing a confirmation could run. Stage a draft and queue_add first.
         - session_plan_unvalidated / session_plan_not_in_namespace: a plan
           somewhere in the queue is a session plan without a current passing
           validation. One stale plan refuses the whole start, all-or-nothing;
@@ -545,7 +592,11 @@ async def queue_start() -> str:
 
     token = get_server_context().launch_token
     if not token:
-        return _refuse_unarmed("queue_start")
+        # The tokenless deployment posture: this server cannot arm — the
+        # launch token lives with the operator's queue panel — so hand the
+        # human the decision instead of dead-ending. The request route is
+        # ungated and arms nothing (no token header exists to send).
+        return await _request_panel_start()
 
     # anyio's run_sync only forwards positional args, and `headers` is
     # keyword-only on `_http_post_json`, hence the lambda.
@@ -565,6 +616,47 @@ async def queue_start() -> str:
     return json.dumps(body)
 
 
+async def _request_panel_start() -> str:
+    """File a start request for the operator's queue panel to confirm.
+
+    ``queue_start``'s tokenless half. The bridge parks the request on the
+    queue summary, every open queue panel renders it as a Confirm control
+    within a poll tick, and the confirmation itself is the panel's own
+    token-gated start — nothing here acquired any arming capability. The
+    kill-switch re-read has already passed in ``queue_start``; it is the one
+    local gate this path shares with the direct start.
+    """
+    status, body = await anyio.to_thread.run_sync(
+        lambda: _http_post_json("/queue/start-request", {"requested_by": "agent"}, headers=None)
+    )
+    if status != 200:
+        return _relay_refusal(
+            body,
+            status,
+            fallback_hints=["Check queue_list for the queue's current state."],
+        )
+
+    record = body.get("start_request") if isinstance(body, dict) else None
+    await anyio.to_thread.run_sync(
+        functools.partial(notify_agent_activity, "queue_start", "run", detail="start-request")
+    )
+    return json.dumps(
+        {
+            "started": False,
+            "start_request": record,
+            "message": (
+                "This deployment keeps the launch token with the operator's BLUESKY "
+                "queue panel, so the agent cannot start the queue directly — that is "
+                "the intended arming posture, not an error. A start request has been "
+                "filed and is now visible in the queue panel: tell the operator their "
+                "confirmation is waiting there, then watch queue_status/queue_list "
+                "for the start. Do not attempt to obtain a token or edit "
+                "configuration; only the panel's Confirm control arms the queue."
+            ),
+        }
+    )
+
+
 # ---------------------------------------------------------------------------
 # Tool 5: stop the queue (asymmetric: halting is free, un-halting is armed)
 # ---------------------------------------------------------------------------
@@ -604,7 +696,9 @@ async def queue_stop(cancel: bool = False) -> str:
         - writes_disabled (cancel=True only): writes are off, so a pending stop
           cannot be withdrawn. A plain stop is never refused for this reason.
         - launch_token_required (cancel=True only): no launch token here or at
-          the bridge, or the two do not match.
+          the bridge, or the two do not match. In deployed terminals the agent
+          holds no token by design — ask the operator to withdraw the stop
+          from their queue panel instead; never chase the token in config.
         - manager_not_configured / manager_unreachable: the manager could not
           be reached. The queue was NOT stopped — say so plainly; do not report
           an unconfirmed halt as done.
diff --git a/src/osprey/profiles/presets/control-assistant.yml b/src/osprey/profiles/presets/control-assistant.yml
index 18aceb1e7..af604762c 100644
--- a/src/osprey/profiles/presets/control-assistant.yml
+++ b/src/osprey/profiles/presets/control-assistant.yml
@@ -68,7 +68,10 @@ rules:
 
 skills:
   - diagnose        # Run a structured fault-diagnosis workflow
-  - setup-mode      # Toggle between interactive and automated operating modes
+  # setup-mode (config diagnostics + setup_patch) is deliberately NOT part of
+  # the operator tier: it can patch config.yml/.mcp.json, which is admin work.
+  # Add it to an admin-facing profile's skills list to opt in — it remains in
+  # the artifact catalog.
   - session-report  # Summarise session actions and outcomes to the logbook
   - demo-gallery    # Launch guided capability demonstrations
   - demo-ui         # Run a scripted demo of the agent driving the web workspace
diff --git a/src/osprey/services/bluesky_bridge/queue.py b/src/osprey/services/bluesky_bridge/queue.py
index 930741561..a79bf5221 100644
--- a/src/osprey/services/bluesky_bridge/queue.py
+++ b/src/osprey/services/bluesky_bridge/queue.py
@@ -32,6 +32,14 @@
 somehow has a plan running is a deployment that must be able to stop it,
 whatever its capability record says.
 
+``POST /queue/start-request`` / ``DELETE /queue/start-request`` — the bridge's
+one concession to callers WITHOUT the token (deployed web terminals, where the
+token lives with the operator panels sidecar and never enters the agent's
+environment): filing publishes a "please start" record on the queue summary
+for a token holder to confirm in the queue panel. Both routes are ungated and
+declare no token header — a request arms nothing, and the only confirmation
+path is the existing token-gated ``POST /queue/start``.
+
 The gate is race-free by construction, twice over. First, ``_arming_lock``
 serializes the enqueue critical section {status-check + add + re-check} and
 the start critical section {idle-check + interruption-gate + session-gate +
@@ -69,11 +77,12 @@
 import json
 import logging
 import uuid
+from datetime import UTC, datetime
 from typing import Any, NoReturn
 
 from fastapi import APIRouter, Header, HTTPException
 from fastapi.responses import StreamingResponse
-from pydantic import BaseModel
+from pydantic import BaseModel, Field
 
 from . import document_plane, draft, runs
 from .queue_backend import (
@@ -145,6 +154,15 @@
 _change_event = asyncio.Event()
 _last_summary: dict[str, Any] | None = None
 
+# The one OTHER bridge-local record this module holds: the pending start
+# request an untokened caller (the agent, in deployments where the launch
+# token lives with the operator panel and never enters the agent's
+# environment) has filed for a token holder to confirm. Not queue state — the
+# manager knows nothing of it — and deliberately ephemeral: losing it on a
+# restart loses a UI affordance, never a safety property, because the ONLY
+# thing that ever starts the queue remains the token-gated POST /queue/start.
+_start_request: dict[str, Any] | None = None
+
 
 def _get_backend() -> QueueBackend:
     """The process's single `QueueBackend`, via `app.py`'s shared accessor.
@@ -165,9 +183,10 @@ def _clear() -> None:
     it, and the next test may run on a fresh loop. The backend singleton
     lives in `app.py` (`set_queue_backend(None)` resets it) — not here.
     """
-    global _last_summary, _arming_lock, _change_event
+    global _last_summary, _arming_lock, _change_event, _start_request
     _stop_poller()
     _last_summary = None
+    _start_request = None
     _subscribers.clear()
     _arming_lock = asyncio.Lock()
     _change_event = asyncio.Event()
@@ -573,18 +592,30 @@ async def _check_devices_exist(backend: QueueBackend, plan_name: str, plan_args:
 
 
 def _status_summary(status: dict[str, Any]) -> dict[str, Any]:
-    """The bounded, diffable projection of a manager status document."""
+    """The bounded, diffable projection of a manager status document.
+
+    ``start_request`` is the one summary entry that is bridge-local rather
+    than read from the status document; carrying it here is what makes a
+    filed or dismissed request reach SSE subscribers through the same
+    summary-diff the manager-side keys use.
+    """
     summary: dict[str, Any] = {"available": True}
     for key in _SUMMARY_KEYS:
         summary[key] = status.get(key)
+    summary["start_request"] = _start_request
     return summary
 
 
 def _unavailable_summary(reason: str) -> dict[str, Any]:
-    """The summary published when the manager (or backend) cannot be read."""
+    """The summary published when the manager (or backend) cannot be read.
+
+    A pending start request survives a manager outage — it is bridge-local
+    state, and the confirm path re-answers for itself when the human clicks.
+    """
     summary: dict[str, Any] = {"available": False, "reason": reason}
     for key in _SUMMARY_KEYS:
         summary[key] = None
+    summary["start_request"] = _start_request
     return summary
 
 
@@ -753,6 +784,17 @@ class QueueStopRequest(BaseModel):
     cancel: bool = False
 
 
+class StartRequestBody(BaseModel):
+    """Body for `POST /queue/start-request` (optional in its entirety).
+
+    ``requested_by`` is a display label for the confirm affordance ("the
+    agent requests…"), never an identity the bridge trusts for anything —
+    the request arms nothing regardless of who filed it.
+    """
+
+    requested_by: str = Field(default="agent", min_length=1, max_length=80)
+
+
 # ---------------------------------------------------------------------------
 # Routes
 # ---------------------------------------------------------------------------
@@ -1043,10 +1085,104 @@ async def start_queue(x_launch_token: str = Header(default="")) -> dict[str, Any
             result = await backend.start()
     except QueueBackendError as exc:
         raise _http_error(exc) from exc
+    # An armed start consumes any pending start request — whether it WAS the
+    # confirmation (a token holder answering the agent) or simply overtook it,
+    # the queue is now doing the thing the request asked for.
+    global _start_request
+    _start_request = None
     _notify_change()
     return {"started": True, "msg": str(result.get("msg") or "")}
 
 
+@router.post("/queue/start-request")
+async def request_queue_start(body: StartRequestBody | None = None) -> dict[str, Any]:
+    """File a request for a launch-token holder to start the queue. Ungated.
+
+    The deployed posture this exists for: the launch token is minted into the
+    operator panels sidecar and never into the agent's environment, so the
+    agent can compose, stage, and enqueue — but only a human, in the queue
+    panel, can arm. This route is how the agent hands the human that decision
+    without acquiring any arming capability itself: filing publishes a record
+    on the queue summary (and its SSE stream), where the panel renders it as a
+    confirm affordance next to the very queue items it would drain. The
+    confirmation is the EXISTING token-gated ``POST /queue/start`` — this
+    route adds no second way to start anything, and like ``POST /queue/abort``
+    it declares no token header at all, so no later edit can quietly promote
+    it into one.
+
+    Refusals mirror the checks a real start would fail, so the requester
+    hears them immediately instead of parking a request no click could ever
+    honour: a deployment that cannot execute refuses with its capability
+    record (same as enqueue), an already-moving queue refuses
+    ``manager_not_idle`` (the drain is already happening), and an empty queue
+    refuses ``queue_empty`` (there is nothing to confirm). The authoritative
+    versions of these checks still run inside the confirm's arming lock —
+    these are a courtesy, not the gate.
+
+    One request at a time: refiling replaces the pending record (fresh
+    ``request_id``), and a successful armed start or an explicit
+    ``DELETE /queue/start-request`` clears it.
+    """
+    backend = _get_backend()
+    try:
+        capability = await backend.capability()
+    except QueueBackendError as exc:
+        raise _http_error(exc) from exc
+    if not capability.can_execute:
+        raise _http_error(ExecutionUnavailableError(capability))
+
+    try:
+        status = await backend.status(reload=True)
+        queue_state = await backend.items()
+    except QueueBackendError as exc:
+        raise _http_error(exc) from exc
+
+    running_item = queue_state.get("running_item")
+    if _requires_arming(status):
+        _refuse_manager_not_idle(running_item if isinstance(running_item, dict) else {})
+
+    items_in_queue = int(status.get("items_in_queue") or 0)
+    if items_in_queue == 0:
+        raise HTTPException(
+            status_code=409,
+            detail={
+                "code": "queue_empty",
+                "detail": (
+                    "the queue holds no items, so there is nothing a start could run — "
+                    "stage a draft and enqueue it (POST /queue/items) before requesting "
+                    "a start."
+                ),
+            },
+        )
+
+    record = {
+        "request_id": uuid.uuid4().hex[:12],
+        "requested_by": (body or StartRequestBody()).requested_by,
+        "requested_at": datetime.now(UTC).isoformat(timespec="seconds"),
+        "items_in_queue": items_in_queue,
+    }
+    global _start_request
+    _start_request = record
+    _notify_change()
+    return {"start_request": record}
+
+
+@router.delete("/queue/start-request")
+async def dismiss_queue_start_request() -> dict[str, Any]:
+    """Withdraw the pending start request. Ungated and idempotent.
+
+    Declining to start is the safe direction — like the plain stop, it must
+    never have a failure mode, so no token, no capability check, and a dismiss
+    with nothing pending is a 200 ``{"dismissed": false}``, not an error.
+    """
+    global _start_request
+    dismissed = _start_request is not None
+    _start_request = None
+    if dismissed:
+        _notify_change()
+    return {"dismissed": dismissed}
+
+
 @router.post("/queue/stop")
 async def stop_queue(
     body: QueueStopRequest | None = None, x_launch_token: str = Header(default="")
diff --git a/src/osprey/templates/claude_code/claude/settings.json.j2 b/src/osprey/templates/claude_code/claude/settings.json.j2
index e269e3dbb..0cf9f250d 100644
--- a/src/osprey/templates/claude_code/claude/settings.json.j2
+++ b/src/osprey/templates/claude_code/claude/settings.json.j2
@@ -28,6 +28,18 @@
   },
   "_PROMPT_PROVIDER_NOTE": "Permissions policy: allow/deny/ask lists. Framework defaults merged with facility overrides from claude_code.permissions config.",
   "enableAllProjectMcpServers": true,
+{#- Claude Code ships harness-configuration skills with the CLI itself, so they
+    are present in every deployed terminal uninvited. An OSPREY operator agent
+    must never reconfigure its own harness (settings.json permissions, env
+    vars, hooks, keybindings) — that is admin work done through the profile and
+    regen, not live edits — so the harness-config family is switched off
+    entirely: hidden from the model, hidden from the / menu, and invoking one
+    by name returns an error instead of running. -#}
+  "skillOverrides": {
+    "update-config": "off",
+    "keybindings-help": "off",
+    "fewer-permission-prompts": "off"
+  },
   "permissions": {
     "allow": [
 {#- Build allow list from server registry -#}
diff --git a/src/osprey/templates/claude_code/claude/skills/operating-bluesky-scans/SKILL.md b/src/osprey/templates/claude_code/claude/skills/operating-bluesky-scans/SKILL.md
index 5f2214956..098ff2e60 100644
--- a/src/osprey/templates/claude_code/claude/skills/operating-bluesky-scans/SKILL.md
+++ b/src/osprey/templates/claude_code/claude/skills/operating-bluesky-scans/SKILL.md
@@ -136,12 +136,37 @@ control. It runs **the queue as it stands — every pending item, in order**,
 not just the one you added. Read `queue_list()` first and be sure the whole
 queue is what should run.
 
+`queue_start` has **two success shapes**, decided by where this deployment
+keeps the launch token, and you must recognize both:
+
+- **`{"started": true, ...}`** — this MCP server holds the token (typical for
+  a host-run dev session). The start went to the bridge directly, behind your
+  approval prompt, and the queue is now draining.
+- **`{"started": false, "start_request": {...}, "message": ...}`** — this
+  server holds **no** token, which in a deployed control room is the intended
+  posture, not a misconfiguration: the token lives with the operator's
+  BLUESKY queue panel, and no environment variable, config edit, or retry
+  from your side can obtain it. Your call filed a **start request** that is
+  now showing in the human's queue panel, beside the very queue it would
+  drain, with a *Confirm start* control only the panel can honour. Tell the
+  operator their confirmation is waiting in the queue panel, then watch
+  `queue_status`/`queue_list` for the start. Calling `queue_start` again
+  replaces the pending request (it does not stack); the human can also
+  dismiss it, which starts nothing.
+
+Never respond to the second shape by hunting for the token, editing
+configuration, or entering a setup mode — the tokenless environment is the
+deployment working as designed, and the human's panel click is the missing
+step, not a missing setting.
+
 **`queue_list()`** is the read surface for all of this, and is the same view
 the human's queue panel shows. It returns `{status, items, running_item}`:
 `status` carries `available`, `manager_state`, `items_in_queue`,
-`queue_stop_pending` and `queue_autostart_enabled`; `items` are the pending
-items in execution order with their `item_uid`, plan `name` and `kwargs`; and
-`running_item` is the item under way (`null` when idle).
+`queue_stop_pending`, `queue_autostart_enabled` and `start_request` (the
+pending panel start request, or `null` — non-null means the operator has not
+confirmed or dismissed it yet); `items` are the pending items in execution
+order with their `item_uid`, plan `name` and `kwargs`; and `running_item` is
+the item under way (`null` when idle).
 
 ---
 
@@ -181,8 +206,11 @@ the layer doing the work here.)
 The bridge alone knows the queue server's live state, under a lock, so it is
 what decides whether a particular call was armed:
 
-- **`queue_start`** is always armed: it needs the launch token, and it is
-  approval-gated so a human sees the start.
+- **`queue_start`** is always armed: starting needs the launch token, and it
+  is approval-gated so a human sees the start. When this server holds a token
+  the start goes to the bridge directly; when it holds none, the same call
+  files a panel start request instead (see Step 2) — the token requirement is
+  never waived, it is answered by the human's confirm click.
 - **`queue_add`** is armed only *sometimes*. Adding to an idle queue moves
   nothing; adding to a queue that is already draining (`manager_state` of
   `executing_queue`, `starting_queue`, `executing_task` or `paused`, or
@@ -203,13 +231,23 @@ whole detail object comes through as `details`. Nothing is reworded, so branch
 on the code and relay the bridge's sentence to the operator as written.
 
 - **`launch_token_required`** — this operation is armed and the token was
-  missing or rejected. For a `queue_add`, `details.manager_state` names the
-  state that made it armed, and the suggestions say whether the deployment has
-  no token or this server withheld one because writes are disabled. Neither is
-  agent-recoverable: an operator must enable writes or configure the token.
+  missing or rejected. You will see it from `queue_add` onto an
+  already-draining queue, from `queue_stop(cancel=True)`, or from the bridge
+  rejecting a mismatched token — never from a tokenless `queue_start`, which
+  files a panel start request instead. Not agent-recoverable, and NOT a
+  configuration task for you: in deployed control rooms the token lives with
+  the operator's queue panel by design, so hand the action to the human —
+  the panel performs these operations with its own token. Never edit
+  config.yml, `.env`, or settings to obtain a token. For a `queue_add`,
+  `details.manager_state` names the state that made it armed, and the
+  suggestions say whether this server withheld the token because writes are
+  disabled (then enabling writes, an operator action, is what unblocks it).
   If `details.item_left_behind` is true, an item could not be withdrawn and is
   sitting in an armed queue — `details.item_uid` names it, and a human must
   deal with it. Say so.
+- **`queue_empty`** — a tokenless `queue_start` found nothing queued, so there
+  was nothing a confirmation could run and no request was filed. Stage the
+  plan with `set_draft` and add it with `queue_add` first.
 - **`stale_draft_revision`** — the draft changed or was cleared since you
   pinned it. Re-read it with `get_draft` (or re-stage the full configuration
   with `set_draft`), then add the **current** revision.
diff --git a/src/osprey/templates/claude_code/claude/skills/writing-bluesky-plans/SKILL.md b/src/osprey/templates/claude_code/claude/skills/writing-bluesky-plans/SKILL.md
index cdac239a1..ca6b2940a 100644
--- a/src/osprey/templates/claude_code/claude/skills/writing-bluesky-plans/SKILL.md
+++ b/src/osprey/templates/claude_code/claude/skills/writing-bluesky-plans/SKILL.md
@@ -164,7 +164,11 @@ never a substitute for `bps.sleep` inside a plan's own control flow.
    `queue_start()` begins draining it. Both consult the validation record:
    the plan's content hash is re-checked at enqueue **and** again at queue
    start, `queue_start` requires `control_system.writes_enabled` plus the
-   launch token, and a human sees an approval prompt. A refusal whose
+   launch token, and a human sees an approval prompt. In deployments where
+   this server holds no launch token (the deployed-terminal norm — the token
+   lives with the operator's queue panel), `queue_start` instead files a
+   start request the human confirms in that panel; see
+   `operating-bluesky-scans` for the two success shapes. A refusal whose
    `detail.code` starts with `session_plan_` (`session_plan_unvalidated`,
    `session_plan_not_in_namespace`) means exactly one thing: re-validate the
    plan and try again. Use `get_run(run_id)` / `get_run_data(run_id, ...)` to
diff --git a/tests/cli/test_claude_code_integration.py b/tests/cli/test_claude_code_integration.py
index 5fded2fe0..251ca0044 100644
--- a/tests/cli/test_claude_code_integration.py
+++ b/tests/cli/test_claude_code_integration.py
@@ -112,6 +112,24 @@ def test_settings_json_has_hooks_and_permissions(self, project_dir):
         assert "PreToolUse" in data["hooks"]
         assert "PostToolUse" in data["hooks"]
 
+    def test_settings_json_switches_off_harness_config_skills(self, project_dir):
+        """The CLI's own harness-configuration skills are off in every render.
+
+        Claude Code bundles skills like update-config (edits settings.json
+        permissions/env/hooks) with the CLI itself, so they ride into every
+        deployed terminal uninvited. An operator agent must never reconfigure
+        its own harness — that is admin work done through the profile and
+        regen — so the whole family is `"off"`: hidden from the model AND the
+        / menu, and invocation by name errors instead of running.
+        """
+        settings_path = project_dir / ".claude" / "settings.json"
+        data = json.loads(settings_path.read_text())
+
+        overrides = data["skillOverrides"]
+        assert overrides["update-config"] == "off"
+        assert overrides["keybindings-help"] == "off"
+        assert overrides["fewer-permission-prompts"] == "off"
+
     def test_settings_json_denies_filesystem_tools(self, project_dir):
         """Built-in filesystem/shell tools are denied; Task delegated to ask.
 
diff --git a/tests/cli/test_preset_hash_pin.py b/tests/cli/test_preset_hash_pin.py
index 1fe4da4f4..ab660745c 100644
--- a/tests/cli/test_preset_hash_pin.py
+++ b/tests/cli/test_preset_hash_pin.py
@@ -84,12 +84,19 @@
     # signal. The archive work and the panel merge landed either side of this
     # merge, so as above the digests carry both at once. Both extends children
     # inherit it, so all three moved.
-    "control-assistant": "sha256:edf098ea7affaa4ddec708eee5dba46cb5799738c9914526eaf475582e3c0326",
+    # Re-pinned again when setup-mode left the operator skills roster: it can
+    # patch config.yml/.mcp.json (setup_patch), which is admin work, so
+    # operator-tier terminals no longer render it. NOT behavior-neutral — a
+    # rebuilt project loses a skill directory — so the staleness advisory
+    # firing on already-deployed projects is the correct signal. The skill
+    # stays in the artifact catalog for admin profiles to opt into. Both
+    # extends children inherit the roster, so all three digests moved.
+    "control-assistant": "sha256:208c2c6883299235e4a1d9837b125874e57bc6b4231b453f5b67ec89ed3bb8ec",
     "control-assistant-readonly": (
-        "sha256:4cb215e59d6b99ae530c60d6305e97ca8eb459aa4f9d5049f2e329d6e87911ae"
+        "sha256:bf865694846898965b402a805f2312095e3abadbce7a922659b28c800284fe0b"
     ),
     "control-assistant-readwrite": (
-        "sha256:90be07f5620df02e44c40b1b75b8b2ce12a738f06dc816a5a8c0febfa631ec08"
+        "sha256:0d4701ab4c056722f465e1601becf2ad0f6a8c88b131be469659b9ffaa976f40"
     ),
     "hello-world": "sha256:ac9c00d70922c3c88d561f7ffa29af3ccb1650d5a8bfaa13b884563199ce371a",
 }
diff --git a/tests/integration/test_bluesky_queue_contract.py b/tests/integration/test_bluesky_queue_contract.py
index afcb1eea1..1c815ac29 100644
--- a/tests/integration/test_bluesky_queue_contract.py
+++ b/tests/integration/test_bluesky_queue_contract.py
@@ -544,9 +544,9 @@ def test_a_stale_draft_revision_never_reaches_the_manager(
 def test_the_queue_read_publishes_a_bounded_status_summary(
     client: TestClient, manager: MockQueueServer
 ) -> None:
-    """`GET /queue` reports the manager's queue, and only the eight status keys
-    the contract names — the raw status document carries 0MQ material that must
-    never reach a consumer."""
+    """`GET /queue` reports the manager's queue, and only the status keys the
+    contract names (plus the bridge-local ``start_request``) — the raw status
+    document carries 0MQ material that must never reach a consumer."""
     revision = _draft_revision(client)
     assert client.post("/queue/items", json={"draft_revision": revision}).status_code == 200
 
@@ -555,7 +555,7 @@ def test_the_queue_read_publishes_a_bounded_status_summary(
     assert set(body) == {"status", "items", "running_item"}
     assert [item["item_uid"] for item in body["items"]] == ["item-1"]
     assert body["running_item"] is None
-    assert set(body["status"]) == {"available", *queue._SUMMARY_KEYS}
+    assert set(body["status"]) == {"available", "start_request", *queue._SUMMARY_KEYS}
     assert body["status"]["available"] is True
     assert body["status"]["items_in_queue"] == 1
     assert "zmq_secret_key" not in json.dumps(body)
@@ -688,6 +688,194 @@ def test_all_three_arming_routes_refuse_with_one_code(
     assert draft._last_launched_revision == 0
 
 
+# ---------------------------------------------------------------------------
+# POST /queue/start-request — an untokened caller asks a token holder to start
+# ---------------------------------------------------------------------------
+
+
+def _enqueue(client: TestClient, num_points: int = 3) -> None:
+    resp = client.post("/queue/items", json={"draft_revision": _draft_revision(client, num_points)})
+    assert resp.status_code == 200, resp.text
+
+
+def test_filing_a_start_request_parks_it_and_starts_nothing(
+    client: TestClient, manager: MockQueueServer
+) -> None:
+    """The request is a published record, not an action: the manager sees no
+    start, and the queue summary carries the record for every consumer."""
+    _enqueue(client)
+
+    resp = client.post("/queue/start-request", json={"requested_by": "agent"})
+    assert resp.status_code == 200, resp.text
+    body = resp.json()
+    assert "code" not in body
+    record = body["start_request"]
+    assert record["requested_by"] == "agent"
+    assert record["items_in_queue"] == 1
+    assert isinstance(record["request_id"], str) and record["request_id"]
+    assert isinstance(record["requested_at"], str) and record["requested_at"]
+
+    # Nothing was armed: no start reached the manager, the item still sits there.
+    assert "queue_start" not in manager.method_names()
+    assert manager.manager_state == "idle"
+
+    # The record rides the queue summary — the same place panels read state.
+    summary = client.get("/queue").json()["status"]
+    assert summary["start_request"] == record
+
+
+def test_a_start_request_defaults_its_requester(
+    client: TestClient, manager: MockQueueServer
+) -> None:
+    """No body at all is a valid filing; the requester defaults to 'agent'."""
+    _enqueue(client)
+    resp = client.post("/queue/start-request")
+    assert resp.status_code == 200, resp.text
+    assert resp.json()["start_request"]["requested_by"] == "agent"
+
+
+def test_refiling_replaces_the_pending_start_request(
+    client: TestClient, manager: MockQueueServer
+) -> None:
+    """One pending request at a time: refiling replaces, never queues a second."""
+    _enqueue(client)
+    first = client.post("/queue/start-request").json()["start_request"]
+    second = client.post("/queue/start-request").json()["start_request"]
+    assert second["request_id"] != first["request_id"]
+    summary = client.get("/queue").json()["status"]
+    assert summary["start_request"]["request_id"] == second["request_id"]
+
+
+def test_a_start_request_refuses_an_empty_queue(
+    client: TestClient, manager: MockQueueServer
+) -> None:
+    """Nothing to start is a coded refusal, not a dangling request."""
+    resp = client.post("/queue/start-request")
+    assert resp.status_code == 409
+    detail = resp.json()["detail"]
+    assert detail["code"] == "queue_empty"
+    assert isinstance(detail["detail"], str) and detail["detail"]
+    assert client.get("/queue").json()["status"]["start_request"] is None
+
+
+def test_a_start_request_refuses_while_the_queue_is_already_moving(
+    client: TestClient, manager: MockQueueServer
+) -> None:
+    """A running queue has nothing to confirm — same code as a premature start."""
+    _enqueue(client)
+    _enqueue(client, num_points=5)
+    manager.begin_running()
+
+    resp = client.post("/queue/start-request")
+    assert resp.status_code == 409
+    assert resp.json()["detail"]["code"] == "manager_not_idle"
+    assert client.get("/queue").json()["status"]["start_request"] is None
+
+
+def test_a_browse_only_deployment_refuses_a_start_request(
+    client: TestClient,
+    manager: MockQueueServer,
+    connector: Callable[[str | Exception], None],
+) -> None:
+    """A deployment that can never execute must not park confirmable requests."""
+    connector("mock")
+    resp = client.post("/queue/start-request")
+    assert resp.status_code == 409
+    detail = resp.json()["detail"]
+    assert detail["code"] == "browse_only_connector"
+    assert detail["capability"]["can_execute"] is False
+
+
+def test_dismissing_a_start_request_is_ungated_and_idempotent(
+    client: TestClient, manager: MockQueueServer
+) -> None:
+    """Withdrawing a request is the safe direction — no token, ever."""
+    _enqueue(client)
+    client.post("/queue/start-request")
+
+    dismissed = client.delete("/queue/start-request")
+    assert dismissed.status_code == 200
+    assert dismissed.json() == {"dismissed": True}
+    assert client.get("/queue").json()["status"]["start_request"] is None
+
+    again = client.delete("/queue/start-request")
+    assert again.status_code == 200
+    assert again.json() == {"dismissed": False}
+
+
+def test_a_confirmed_start_clears_the_pending_request(
+    client: TestClient, manager: MockQueueServer, monkeypatch: pytest.MonkeyPatch
+) -> None:
+    """The token-gated start IS the confirmation — the record does not outlive it."""
+    monkeypatch.setenv(_TOKEN_ENV, _TOKEN)
+    _enqueue(client)
+    client.post("/queue/start-request")
+
+    started = client.post("/queue/start", headers={"X-Launch-Token": _TOKEN})
+    assert started.status_code == 200, started.text
+    assert client.get("/queue").json()["status"]["start_request"] is None
+
+
+def test_a_refused_start_leaves_the_pending_request_in_place(
+    client: TestClient, manager: MockQueueServer, monkeypatch: pytest.MonkeyPatch
+) -> None:
+    """Only a start that actually armed consumes the request; a refused
+    confirmation (wrong token here) leaves it for the next attempt."""
+    monkeypatch.setenv(_TOKEN_ENV, _TOKEN)
+    _enqueue(client)
+    record = client.post("/queue/start-request").json()["start_request"]
+
+    refused = client.post("/queue/start", headers={"X-Launch-Token": "not-the-token"})
+    assert refused.status_code == 403
+    assert client.get("/queue").json()["status"]["start_request"] == record
+
+
+def test_filing_a_start_request_never_arms_anything_even_with_a_token(
+    client: TestClient, manager: MockQueueServer, monkeypatch: pytest.MonkeyPatch
+) -> None:
+    """The route declares no token header at all — there is nothing a header
+    could elevate it to. Negative control for accidental gating-by-edit."""
+    monkeypatch.setenv(_TOKEN_ENV, _TOKEN)
+    _enqueue(client)
+    resp = client.post("/queue/start-request", headers={"X-Launch-Token": _TOKEN})
+    assert resp.status_code == 200
+    assert "queue_start" not in manager.method_names()
+    assert manager.manager_state == "idle"
+
+
+async def test_the_event_stream_reports_a_start_request_and_its_dismissal(
+    connector: Callable[[str | Exception], None], monkeypatch: pytest.MonkeyPatch
+) -> None:
+    """Filing and dismissing both reach a panel within one poll tick, on the
+    same full-snapshot frames every other queue change rides."""
+    monkeypatch.setattr(queue, "_POLL_INTERVAL_S", 0.01)
+    connector("virtual_accelerator")
+    mock = MockQueueServer()
+    app_module.set_queue_backend(QueueBackend(mock))
+
+    response = await queue.queue_events()
+    frames = response.body_iterator
+    try:
+        hello = _parse_frame(await asyncio.wait_for(frames.__anext__(), timeout=5))
+        assert hello["status"]["start_request"] is None
+
+        revision = await _draft_revision_direct()
+        await queue.add_queue_item(
+            queue.QueueAddRequest(draft_revision=revision), x_launch_token=""
+        )
+        await queue.request_queue_start(queue.StartRequestBody(requested_by="agent"))
+        frame = await _frame_where(frames, lambda f: f["status"]["start_request"] is not None)
+        assert frame["status"]["start_request"]["requested_by"] == "agent"
+
+        await queue.dismiss_queue_start_request()
+        await _frame_where(
+            frames,
+            lambda f: f["status"]["start_request"] is None and f["status"]["items_in_queue"] == 1,
+        )
+    finally:
+        await frames.aclose()
+
+
 # ---------------------------------------------------------------------------
 # POST /queue/abort — the emergency halt, ungated on every axis
 # ---------------------------------------------------------------------------
@@ -1013,7 +1201,7 @@ def _assert_snapshot_frame(frame: dict[str, Any]) -> None:
     """Every frame on this stream is a full snapshot in one fixed shape."""
     assert set(frame) == {"type", "status", "items", "running_item"}
     assert frame["type"] in ("hello", "queue")
-    assert set(frame["status"]) == {"available", *queue._SUMMARY_KEYS}
+    assert set(frame["status"]) == {"available", "start_request", *queue._SUMMARY_KEYS}
     assert frame["status"]["available"] is True
     # Negative control: a snapshot is never a refusal, and never leaks the raw
     # status document's 0MQ material.
diff --git a/tests/interfaces/bluesky_panels/bluesky-panel.test.mjs b/tests/interfaces/bluesky_panels/bluesky-panel.test.mjs
index 2f6677ed3..d8d9d379a 100644
--- a/tests/interfaces/bluesky_panels/bluesky-panel.test.mjs
+++ b/tests/interfaces/bluesky_panels/bluesky-panel.test.mjs
@@ -38,6 +38,7 @@ import {
   createQueueStream,
   describeProgress,
   describeQueueStatus,
+  describeStartRequest,
   historyChanged,
   historyEmptyState,
   historyRecords,
@@ -49,6 +50,7 @@ import {
   queueEmptyState,
   reduceQueueFrame,
   refusalTone,
+  startRequest,
   stopButtonClass,
   stopButtonLabel,
   writeOutcomeTone,
@@ -196,6 +198,75 @@ describe('describeQueueStatus', () => {
   });
 });
 
+describe('start request (the tokenless agent asking this panel to arm)', () => {
+  test('startRequest surfaces the summary record, and only a real one', () => {
+    const record = {
+      request_id: 'r1',
+      requested_by: 'agent',
+      requested_at: '2026-08-12T20:00:00+00:00',
+      items_in_queue: 2,
+    };
+    const withRequest = reduceQueueFrame(
+      createInitialQueueState(),
+      frame({ status: summary({ start_request: record }) })
+    );
+    expect(startRequest(withRequest)).toEqual(record);
+
+    const without = reduceQueueFrame(createInitialQueueState(), frame());
+    expect(startRequest(without)).toBeNull();
+
+    // A summary that never mentions the key, a null status, and a malformed
+    // (non-object) record all read as "nothing to render", never a throw.
+    expect(startRequest(createInitialQueueState())).toBeNull();
+    const malformed = reduceQueueFrame(
+      createInitialQueueState(),
+      frame({ status: summary({ start_request: 'yes please' }) })
+    );
+    expect(startRequest(malformed)).toBeNull();
+  });
+
+  test('the request survives a manager outage frame — it is bridge state', () => {
+    const record = { request_id: 'r1', requested_by: 'agent', items_in_queue: 1 };
+    const outage = reduceQueueFrame(
+      createInitialQueueState(),
+      frame({
+        status: {
+          available: false,
+          reason: 'manager_unreachable',
+          start_request: record,
+        },
+      })
+    );
+    expect(startRequest(outage)).toEqual(record);
+  });
+
+  test('describeStartRequest names who asked, how much, and when', () => {
+    const sentence = describeStartRequest({
+      request_id: 'r1',
+      requested_by: 'agent',
+      requested_at: '2026-08-12T20:00:00+00:00',
+      items_in_queue: 2,
+    });
+    expect(sentence).toContain('The agent asks to start the queue');
+    expect(sentence).toContain('2 items at the time');
+    expect(sentence).toContain('requested ');
+    expect(sentence).toContain('exactly as listed below');
+  });
+
+  test('describeStartRequest omits what it cannot state truthfully', () => {
+    const sentence = describeStartRequest({ request_id: 'r1' });
+    expect(sentence).toContain('The agent asks to start the queue');
+    expect(sentence).toContain('the queued items');
+    expect(sentence).not.toContain('requested ');
+
+    // A singular count reads as one item, not "1 items".
+    expect(describeStartRequest({ items_in_queue: 1 })).toContain('1 item at the time');
+
+    // An unparseable timestamp is dropped, never rendered as "Invalid Date".
+    expect(describeStartRequest({ requested_at: 'not-a-date' })).not.toContain('Invalid');
+  });
+});
+
 describe('queueControls', () => {
   /**
    * @param {any} status
diff --git a/tests/interfaces/bluesky_panels/test_app_integration.py b/tests/interfaces/bluesky_panels/test_app_integration.py
index c55c9600b..d0e08cb05 100644
--- a/tests/interfaces/bluesky_panels/test_app_integration.py
+++ b/tests/interfaces/bluesky_panels/test_app_integration.py
@@ -264,7 +264,7 @@ def test_write_surface_is_exactly_draft_and_queue() -> None:
     # writes relayed verbatim to the bridge -- they never arm or launch a run.
     # No other write verb may exist anywhere in the composed app.
     #
-    # The six /queue writes are the sidecar's relay of the bridge's queue
+    # The /queue writes are the sidecar's relay of the bridge's queue
     # surface (see test_queue_relay.py), and are the ONLY way anything this
     # sidecar serves can put work in front of hardware. They add no policy
     # here: the launch token is resolved in-process and attached to every one
@@ -277,6 +277,11 @@ def test_write_surface_is_exactly_draft_and_queue() -> None:
     # it is listed here for the same reason as the rest -- so a new write route
     # cannot appear without someone justifying it in this list.
     #
+    # The two /queue/start-request writes are likewise writes in the HTTP
+    # sense only: filing parks a "please start" record for a human to answer
+    # (the bridge starts nothing for it) and the DELETE withdraws it. The
+    # arming path they feed is /queue/start, already on this list.
+    #
     # Enumerated deliberately: a new write route must fail this test until
     # someone justifies it in this list.
     write_paths = {
@@ -292,6 +297,8 @@ def test_write_surface_is_exactly_draft_and_queue() -> None:
         ("/queue/items/{uid}/move", "post"),
         ("/queue/items/{uid}", "delete"),
         ("/queue/start", "post"),
+        ("/queue/start-request", "post"),
+        ("/queue/start-request", "delete"),
         ("/queue/stop", "post"),
         ("/queue/abort", "post"),
     }, f"unexpected write surface: {write_paths}"
diff --git a/tests/interfaces/bluesky_panels/test_queue_relay.py b/tests/interfaces/bluesky_panels/test_queue_relay.py
index 17494aad3..7290d6355 100644
--- a/tests/interfaces/bluesky_panels/test_queue_relay.py
+++ b/tests/interfaces/bluesky_panels/test_queue_relay.py
@@ -256,6 +256,30 @@ def test_start_queue_relays_success() -> None:
     assert seen[0].url.path == "/queue/start"
 
 
+def test_start_request_routes_relay_filing_and_dismissal_verbatim() -> None:
+    """Both start-request routes are plain relays: body in, body out, no policy."""
+    record = {"request_id": "r1", "requested_by": "operator", "items_in_queue": 2}
+    app, seen, contents = _recording_app(200, {"start_request": record})
+
+    with TestClient(app) as client:
+        filed = client.post("/queue/start-request", json={"requested_by": "operator"})
+
+    assert filed.status_code == 200
+    assert filed.json() == {"start_request": record}
+    assert seen[0].url.path == "/queue/start-request"
+    assert json.loads(contents[0]) == {"requested_by": "operator"}
+
+    app, seen, contents = _recording_app(200, {"dismissed": True})
+    with TestClient(app) as client:
+        dismissed = client.delete("/queue/start-request")
+
+    assert dismissed.status_code == 200
+    assert dismissed.json() == {"dismissed": True}
+    assert seen[0].method == "DELETE"
+    assert seen[0].url.path == "/queue/start-request"
+    assert contents[0] == b""
+
+
 def test_stop_queue_relays_success_and_forwards_cancel_verbatim() -> None:
     app, seen, contents = _recording_app(200, {"stop_pending": False, "msg": ""})
 
@@ -315,6 +339,8 @@ def test_a_uid_bearing_an_encoded_slash_never_reaches_the_bridge() -> None:
         ("post", "/queue/items/item-a/move", {"pos_dest": "front"}),
         ("delete", "/queue/items/item-a", None),
         ("post", "/queue/start", None),
+        ("post", "/queue/start-request", {"requested_by": "operator"}),
+        ("delete", "/queue/start-request", None),
         ("post", "/queue/stop", {"cancel": False}),
     ],
 )
@@ -341,6 +367,10 @@ def test_every_write_returns_502_when_the_bridge_is_unreachable(
         ("post", "/queue/items/item-a/move", {"pos_dest": "front"}),
         ("delete", "/queue/items/item-a", None),
         ("post", "/queue/start", None),
+        # The bridge gates neither start-request route and ignores this header
+        # on both — same reasoning as the abort below.
+        ("post", "/queue/start-request", {"requested_by": "operator"}),
+        ("delete", "/queue/start-request", None),
         ("post", "/queue/stop", {"cancel": True}),
         # The bridge gates the abort on nothing and ignores this header. It is
         # still on the list: an exception carved out here would be the same
@@ -898,6 +928,7 @@ def test_router_exposes_exactly_the_bridge_queue_surface() -> None:
         "/queue/items/{uid}/move": {"post"},
         "/queue/items/{uid}": {"delete"},
         "/queue/start": {"post"},
+        "/queue/start-request": {"post", "delete"},
         "/queue/stop": {"post"},
         "/queue/abort": {"post"},
         "/queue/events": {"get"},
diff --git a/tests/mcp_server/bluesky/test_queue_tools.py b/tests/mcp_server/bluesky/test_queue_tools.py
index 542d43a3c..527122848 100644
--- a/tests/mcp_server/bluesky/test_queue_tools.py
+++ b/tests/mcp_server/bluesky/test_queue_tools.py
@@ -489,15 +489,55 @@ async def test_queue_start_missing_config_fails_closed(tmp_path, monkeypatch):
     mock_post.assert_not_called()
 
 
-async def test_queue_start_without_a_token_refuses_client_side(tmp_path, monkeypatch):
-    """Writes-enabled alone is not sufficient — and the local refusal uses the wire code."""
+async def test_queue_start_without_a_token_files_a_panel_start_request(tmp_path, monkeypatch):
+    """The tokenless deployment posture: queue_start hands the decision to the human.
+
+    In a deployed web terminal the launch token lives with the operator panels
+    sidecar and never enters the agent's environment — so a tokenless
+    queue_start must not dead-end in a refusal that reads like a config bug.
+    It files ``POST /queue/start-request`` (no token header: the route arms
+    nothing), and the result tells the agent exactly what happens next: the
+    operator confirms in the queue panel. ``/queue/start`` is never called.
+    """
     _configure(tmp_path, monkeypatch, writes=True, token=None)
-    with patch(f"{_MOD}._http_post_json") as mock_post:
-        with assert_raises_error(error_type="launch_token_required") as ctx:
+    record = {
+        "request_id": "abc123",
+        "requested_by": "agent",
+        "requested_at": "2026-08-12T20:00:00+00:00",
+        "items_in_queue": 2,
+    }
+    with patch(f"{_MOD}._http_post_json", return_value=(200, {"start_request": record})) as m:
+        with patch(f"{_MOD}.notify_agent_activity"):
+            result = await _start_fn()()
+
+    assert m.call_args.args[0] == "/queue/start-request"
+    assert m.call_args.kwargs["headers"] is None
+    body = extract_response_dict(result)
+    assert body["started"] is False
+    assert body["start_request"] == record
+    assert "queue panel" in body["message"]
+
+
+async def test_a_tokenless_start_request_relays_bridge_refusals(tmp_path, monkeypatch):
+    """An empty queue refuses the request with the bridge's own code, so the
+    agent hears "enqueue first", not a token problem."""
+    _configure(tmp_path, monkeypatch, writes=True, token=None)
+    body = _refusal("queue_empty", "the queue holds no items")
+    with patch(f"{_MOD}._http_post_json", return_value=(409, body)):
+        with assert_raises_error(error_type="queue_empty") as ctx:
             await _start_fn()()
 
+    assert ctx["envelope"]["details"]["code"] == "queue_empty"
+
+
+async def test_a_tokenless_start_still_respects_the_kill_switch(tmp_path, monkeypatch):
+    """Writes disabled refuses BEFORE any start request is filed: a request the
+    panel shows as confirmable must never exist on a writes-off deployment."""
+    _configure(tmp_path, monkeypatch, writes=False, token=None)
+    with patch(f"{_MOD}._http_post_json") as mock_post:
+        with assert_raises_error(error_type="writes_disabled"):
+            await _start_fn()()
     mock_post.assert_not_called()
-    assert ctx["envelope"]["details"]["code"] == "launch_token_required"
 
 
 @pytest.mark.parametrize(
diff --git a/tests/mcp_server/test_backend_emit_sites.py b/tests/mcp_server/test_backend_emit_sites.py
index b37b30d64..555c3af8b 100644
--- a/tests/mcp_server/test_backend_emit_sites.py
+++ b/tests/mcp_server/test_backend_emit_sites.py
@@ -288,11 +288,27 @@ async def test_queue_start_success_emits(_bluesky_context):
 
 
 async def test_queue_start_client_side_refusal_no_emit(_bluesky_context, monkeypatch):
-    """A client-side refusal (no token) never reaches the emit site.
+    """A client-side refusal (kill switch off) never reaches the emit site.
 
-    ``queue_start`` refuses before any HTTP call when this server holds no
-    launch token, so neither the bridge nor the activity emitter is touched.
+    ``queue_start`` refuses before any HTTP call when writes are disabled, so
+    neither the bridge nor the activity emitter is touched.
     """
+    monkeypatch.setattr(f"{_QUEUE_MOD}._writes_enabled", lambda: False)
+
+    with (
+        patch(f"{_QUEUE_MOD}._http_post_json") as post,
+        patch(f"{_QUEUE_MOD}.notify_agent_activity") as notify,
+    ):
+        with assert_raises_error(error_type="writes_disabled"):
+            await _get_queue_tool("queue_start")()
+
+    post.assert_not_called()
+    notify.assert_not_called()
+
+
+async def test_queue_start_tokenless_emits_the_start_request(_bluesky_context, monkeypatch):
+    """The tokenless path is agent activity too: filing the panel start
+    request emits under the same tool name, marked as a request."""
     from osprey.mcp_server.bluesky.server_context import (
         initialize_server_context,
         reset_server_context,
@@ -302,15 +318,17 @@ async def test_queue_start_client_side_refusal_no_emit(_bluesky_context, monkeyp
     reset_server_context()
     initialize_server_context()
 
+    body = {"start_request": {"request_id": "r1", "requested_by": "agent"}}
     with (
-        patch(f"{_QUEUE_MOD}._http_post_json") as post,
+        patch(f"{_QUEUE_MOD}._http_post_json", return_value=(200, body)) as post,
         patch(f"{_QUEUE_MOD}.notify_agent_activity") as notify,
     ):
-        with assert_raises_error(error_type="launch_token_required"):
-            await _get_queue_tool("queue_start")()
+        await _get_queue_tool("queue_start")()
 
-    post.assert_not_called()
-    notify.assert_not_called()
+    assert post.call_args.args[0] == "/queue/start-request"
+    assert notify.call_count == 1
+    assert notify.call_args.args[:2] == ("queue_start", "run")
+    assert notify.call_args.kwargs["detail"] == "start-request"
 
 
 # ── artifact focus tools ────────────────────────────────────────────────────