[BUG] /goal after any leading text is silently ignored — goal never set, no feedback, and the model improvising masks the failure

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report
• [x] I am using the latest version of Claude Code (2.1.170)

What's Wrong?

/goal (added in 2.1.139) is a mode-setting command — it's supposed to persist across turns and keep the agent working until the condition is met. But if there is any text before the /goal token in the message, the entire line is silently forwarded to the model as prose: the goal is never set, there is no warning, and — this is the part that makes it really misleading — the model frequently improvises on the raw text and partially does the work anyway. So the user believes goal mode is running when it isn't, and long autonomous runs quietly lack the cross-turn goal loop they were counting on.

In practice this happens constantly with exactly the kind of input /goal is designed for: long directives. Users compose a paragraph and embed the command ("here's the context… /goal <condition>"), or paste a prepared multi-line directive where /goal ends up after a leading line. Same outcome every time: silent no-op, plausible-looking improvised response.

The inconsistency with neighboring failure modes makes it worse — every other near-miss is loud:

| Input | Behavior |
|---|---|
| /goal <condition> (first token) | ✅ goal set, works |
| some text… /goal <condition> | ❌ silent — sent as prose, goal never set, model improvises |
| / goal <condition> (space after slash) | Loud: `Commands are in the form /command [args] |
| /fooxyz <args> (undefined command) | Loud: Unknown command: /fooxyz` |

A one-character typo and a nonexistent command both get immediate feedback; the most common real-world slip (text before the command) is the only one that fails silently.

What Should Happen?

Any of these would fix it (in descending order of preference):

1. Warn when a known slash command appears after leading text: "/goal found mid-message — slash commands must start the message. No goal was set." Cheap to detect (token matches a registered command name), eliminates the silent class entirely.
2. Make goal state visible/checkable at a glance so "is goal mode actually on?" never requires guessing — the overlay panel exists once a goal IS set; the problem is there's no signal in the failure case.
3. Alternatively, recognize a registered command token at the start of any line within the message.

Related discoverability nit while debugging this: the binary contains "/goal is only available in trusted workspaces". That gating means the identical invocation works in one project and not in another, which compounds the "sometimes works, sometimes not" perception — worth surfacing prominently wherever the goal fails to set.

Error Messages/Logs

# Step 1 — /goal embedded after leading text (fresh session):
$ claude -p 'please do this: /goal a file named never.txt exists in the current directory'
Done: `never.txt` now exists in /private/tmp/goal-repro — verified with `ls -la` ...
One note: `/goal` isn't an available skill or command in this session, so I executed
the stated criterion directly instead of routing through it.

# Step 2 — goal status in the SAME conversation:
$ claude -p -c '/goal'
No goal set. Usage: `/goal <condition>`

Note the model itself reports /goal "isn't available" and improvises — it happened to satisfy the one-shot criterion here, which is exactly how the silent failure masquerades as success. No persistent goal was ever registered (step 2).

Steps to Reproduce

1. In an empty directory, run:

``bash
claude -p 'please do this: /goal a file named never.txt exists in the current directory'
``
Observed: the line is handed to the model as plain text. No goal indicator, no warning. The model improvises over the prose.

1. Confirm no goal was registered, in the same conversation:

``bash
claude -p -c '/goal'
`
Observed: No goal set. Usage: /goal <condition>`

1. Contrast with the loud failure modes:

``bash
claude -p '/ goal anything' # → Commands are in the form /command [args]
claude -p '/fooxyz anything' # → Unknown command: /fooxyz
``

1. Positive control — first-token invocation works:

``bash
claude -p '/goal a file named proof.txt exists in the current working directory containing exactly the text DONE'
``
Observed: goal engages, agent works until met, file exists with exact content.

Same silent behavior in interactive mode, where it's most damaging: a pasted multi-line directive with /goal after a leading sentence submits as an ordinary prompt with no feedback.

Environment

• Claude Code: 2.1.170
• OS: macOS 26.0 (Darwin 25.0.0)
• Shell: zsh
• Terminal: cmux (Ghostty-based)