[Bug]: Attaching an image silently disables slash-command/skill expansion for the whole message (Claude provider)

[grechman]

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Closest existing issues, none of which cover this: #7671 (pickers offer entries that cannot run; $ flattens to text; / menu opens on any line start), #7795 (provider-agnostic $skill), #3594 (duplicate execution when the first message is only a skill). Those are about which entries the pickers offer and where in the message the token sits. This one is about an attachment dropping an invocation that is otherwise valid and correctly placed.

Area

apps/web

Steps to reproduce

1. Claude provider, any thread, any user skill installed (~/.claude/skills/flow-patterns/SKILL.md).
2. Send exactly /flow-patterns hello, no attachment. The skill expands: the turn receives <command-name>/flow-patterns</command-name>, <command-args>hello</command-args>, and the full SKILL.md body.
3. Send the identical text /flow-patterns hello with any image attached (paste or drag).
4. Inspect the turn the agent actually received.

Expected behavior

Expansion should not depend on whether the message carries an attachment. /flow-patterns hello + an image should deliver the same expanded command it delivers without one, or fail loudly if the combination is unsupported.

Actual behavior

With an attachment, nothing expands. The agent receives the literal string /flow-patterns hello plus the image. No <command-message>, no <command-name>, no skill body, and no error or warning is shown anywhere in the UI, so from the user's side the send looks identical to the working case.

I isolated this by changing one variable at a time; only the attachment matters:

message	attachment	commands	command in mid-prose	expanded
/web-css	no	1	no	yes
/flow-patterns hello	no	1	no	yes
/flow-patterns /notarealcommand	no	1	no	yes
/flow-patterns /lookover	no	2	no	yes (leading command only)
/flow-patterns hello	1 image	1	no	no
/flow-patterns /lookover ...prose... /web-scaffold	3 images	3	yes	no

The last row is what I hit in real use and first misdiagnosed as a multiple-command problem. Rows 3 and 4 rule that out. A bare /token and a second real command name both leave the leading command's expansion intact, though the second command is itself swallowed into <command-args> rather than run, which is a separate limitation tracked in #7795. The only variable that differs between rows 2 and 5 is the attachment.

The practical cost is high because attachment plus skill is a natural pairing. Running a design skill on a screenshot, or a review skill on a pasted log, means putting the image and the command in one message, and that is the combination that drops the command. The agent then answers from general knowledge, and nothing in the thread indicates the skill never loaded.

I could not determine which layer drops it. Both are candidates: the T3 send path may flatten the composer command to text when the message carries attachments, or the claude CLI may decline expansion for a multimodal prompt. ~/.t3/userdata/logs/provider/events.<thread>.log records no outbound user-prompt events (only turn.started with a bare {"model": ...} payload, plus assistant and tool traffic), so it cannot discriminate from the client side.

Impact

Major degradation or frequent failure

Version or commit

t3code-nightly-bin 0.0.34_nightly.20260820.1142 (AUR)

Environment

Arch Linux, kernel 7.1.8-arch1-3, desktop app, Claude provider, claude CLI 2.1.241, model Claude Opus 5.

Workaround

Send the skill invocation as its own message with no attachment, then send the attachment in a follow-up. Or skip the prefix and name the skill in prose ("use flow-patterns on this image"), which lets the agent invoke it through its own Skill tool - though that does not work for skills marked disable-model-invocation: true, whose only valid entry point is explicit user invocation.