Feature request: agent-requestable /goal arming with one-keypress user confirmation

Problem

/goal (the session-scoped Stop-hook goal mode, v2.1.139+) is exactly the right mechanism for long-running autonomous work, but it is operator-armed only, and in practice operators don't know it exists or when to arm it. We run a clean-room evaluation program for autonomous inference-optimization agents (multi-hour, GPU-cluster engagements driven by an agent skill pack), and this gap produced repeated, measurable failures:

1. Tribal knowledge: sessions whose own instructions describe the work as "long-running, unattended" still stall at turn boundaries within minutes unless a human who happens to know about /goal arms it at the right moment ("Continue from where you left off" hand-nudging). New operators never discover the feature.
2. The agent knows, but can't act: our skill pack now instructs the agent to tell the operator to arm goal mode at a specific checkpoint. That works — but it's a workaround: the agent has all the information needed (objective, budget, valid stop conditions elicited from the user earlier) and no sanctioned way to act on it.
3. Cross-harness comparison: OpenAI's Codex CLI (0.147) exposes model-facing goal tools — we verified empirically that a plain prompt causes the agent to create a persistent, token-budget-tracked goal on its own thread (headless, no TUI), which then survives session resumes. In our A/B evaluations, goal-armed Claude Code sessions ran productively unattended for 16+ hours; unarmed but otherwise identical sessions stalled immediately. The capability gap is now the main operational difference between the harnesses for this class of work.

Proposed feature

Agent-requestable goal arming with explicit user confirmation. A tool or affordance by which the agent can request goal mode: the request surfaces to the user as a confirmation dialog with the agent-proposed condition text and optional bounds prefilled (objective, turn/time bounds, valid stop conditions), and one keypress arms it. Decline is equally one keypress.

This keeps a clean safety asymmetry we'd suggest as the design principle: an agent may request to bind itself more tightly (persistence toward a stated objective within stated bounds), but never to loosen itself — stopping conditions, budget grants, and goal clearing remain user-controlled. The human stays in the loop for the decision while the knowledge burden ("what is /goal, when do I type it, what should the condition say") moves to the agent, which is the party that actually has that context.

Complementary smaller asks, either of which would also help:

• A settings-level standing goal/Stop-hook configuration for dedicated unattended rigs (arm-by-default with a configured condition template).
• Surfacing goal mode in first-run/onboarding docs for long-running sessions — today it's effectively undiscoverable.

Evidence available

We have detailed session transcripts (stall-and-nudge patterns, the 16-hour goal-armed run, the Codex self-arming verification) from a controlled multi-harness study and are happy to share specifics.

Filed from an agent-evaluation program at NVIDIA; drafted with Claude Code.