Preflight Checklist
What's Wrong?
CLAUDE TOLD ME TO SEND THIS.
Session UX Feedback for Anthropic
A running list of small usability/self-awareness gaps noticed during a live Claude
Code session, compiled at the user's request so they can pass them along as feedback.
None of these are the model's "fault" in any meaningful sense — they're gaps in what
information the surrounding product actually gives the model to work with.
Item 1: File attachments from Claude Desktop app not reaching the session's filesystem
Summary
Images attached via the Claude Desktop app's file-attach control appeared normally in
the conversation UI (rendered visually, described accurately by the model) but never
arrived as an actual file the backend session could access. The same attachment action
performed moments later from the Claude mobile app worked correctly on the first try.
This makes any tool-based processing of the image (resizing, cropping, saving as a
project asset, etc.) impossible when attaching from the affected Desktop build, even
though the user sees no error and the image displays fine in the chat.
Environment
Client where the bug occurred: Claude Desktop app, per the user "since the
[most recent] update" — exact version unknown, but the user notes the same update
otherwise improved stability ("you ordinarily would have crashed several times by
now for me on this weak little laptop").
Client where it worked correctly: Claude mobile app (same account, same
conversation, immediately after).
Underlying environment: Claude Code session (remote/cloud execution), where
attachments are expected to be saved server-side to a per-session uploads directory
and surfaced to the model via an internal Read-tool call.
Steps to reproduce (as observed)
In an ongoing Claude Desktop conversation, use the attach-file / paperclip control
to attach an image (not drag-and-drop, not paste — the user confirmed they used the
dedicated attach button both times).
Send the message.
The image renders normally in the conversation thread for the user, and the model
receives and can visually describe the image's contents.
Expected: the file is saved to the session's uploads directory and a
Read tool call system-reminder appears referencing its path, exactly as it does
for every other successful attachment in the session — making the file available
to shell/file tools.
Actual: no such system-reminder appears, and no new file is created anywhere
under the session's writable filesystem within several minutes of the message being
sent (confirmed via a filesystem-wide search for recently modified image files).
The model has only the rendered/visual representation of the image in context, with
no backing file — any attempt to read, copy, or process it via file tools fails
because there is nothing on disk to point to.
Evidence gathered during the session
Two separate images were attached this way, in two separate messages, from the
Desktop app. Neither produced a file in /root/.claude/uploads//, and
neither was preceded by a "Called the Read tool" system-reminder (the pattern every
other attachment in the session produced).
A third image, sent immediately after via the Claude mobile app, succeeded
immediately: it appeared as /root/.claude/uploads//d6590e5a-1000001658.webp
with the expected system-reminder, and was fully readable/processable.
The user independently confirmed they used the same attach-button workflow both
times on Desktop, ruling out user error (e.g., accidentally pasting instead of
attaching) as the cause on at least the second attempt.
Impact
Silent failure mode: the user receives no error, warning, or visual difference
between a successful and failed attachment. The only symptom is that the model's
downstream actions (e.g., "resize this image and add it to the file") can't
actually be carried out, and the user has to notice that nothing changed.
This is especially misleading in agentic/tool-using contexts (like Claude Code),
where the user reasonably expects an attached file to be operable by shell/file
tools once it appears in the chat.
Suggested next steps for investigation
Compare the upload code path between the affected Desktop build and the mobile
app build to find where the file fails to be persisted/forwarded to the session
environment.
Consider surfacing an explicit error/toast in the Desktop client if an attachment
fails to reach the backend, rather than only rendering it client-side.
If this is a regression from a recent Desktop release, a version bisect against
that release would likely narrow it down quickly given how reproducible it was here
(2/2 failures on Desktop, 1/1 success on mobile, same account, same conversation).
Item 2: The model has no reliable way to know which client (mobile vs. desktop) the user is currently on
Summary
While troubleshooting Item 1, the model repeatedly had to guess or take the user's
word for which app they were using (Desktop vs. mobile), because nothing in the
session context reliably identifies the originating client on a per-message basis.
This led directly to a wrong assumption: the model told the user to try the
"attachment/photo picker button" as if switching away from pasting would fix things,
when the user was in fact already using that exact control on Desktop — the model's
guess about what the user was doing was downstream of not actually knowing which
client they were on.
Why this matters
The model can currently only infer client/device from indirect, unreliable signals:
the user's own statements ("I'm on desktop today"), or circumstantial evidence like
whether an attached file happens to land on disk. Neither is something the model
should have to rely on for a fact the surrounding product almost certainly already
knows at the infrastructure level (which app/platform sent the request).
This isn't just a convenience issue — it's a self-awareness gap. A model that is
asked "am I on your desktop or phone right now?" should be able to answer from
session metadata, the same way it can already tell working directory, git branch,
or platform/OS. Right now it can't, so it either guesses or has to ask.
One session-level field (an "entrypoint" value suggesting the session originated
from mobile) was visible in the underlying transcript file, but this is (a) not
something exposed to the model as a normal, documented field it should rely on, and
(b) session-level rather than per-message, so it wouldn't have reflected the
mid-session switch to Desktop and back to mobile that actually happened here.
Suggested next steps for investigation
Expose a lightweight, per-message (or per-turn) "client" field to the model in the
same way other environment facts are surfaced (e.g. alongside working directory /
platform info), so the model can answer this correctly without asking, and can
reason accurately about client-specific quirks (like Item 1) as they arise.
If a stable per-message signal isn't feasible, even a session-level "current client"
value that updates when the user switches apps would be an improvement over the
static, undocumented field currently only visible by inspecting internal transcript
files directly.
Item 3: The model asserted a UI feature (thumbs up/down feedback buttons) that doesn't exist in Claude Code
Summary
When asked how to submit Item 1 as feedback, the model suggested using "in-app
feedback (thumbs-down / 'Report a bug' on the relevant message)" as the most direct
route. The user, working in Claude Code, corrected this: no such buttons exist in
that surface. The model was speaking from general familiarity with feedback controls
that exist on other Claude surfaces (e.g. claude.ai) without being certain they apply
to Claude Code specifically, and stated it as fact rather than flagging the
uncertainty.
Why this matters
This is the same root shape as Item 2: the model doesn't have a reliable way to
know exactly which UI affordances are present on the specific surface the user is
currently using, so it fills the gap with a plausible-sounding but unverified
assumption instead of either checking or saying "I'm not sure this exists on this
surface."
Low stakes here (the user just corrected it and moved on), but the same failure
mode — confidently describing a UI element the model can't actually see or verify —
could be more costly in other contexts (e.g. walking a user through steps that
don't exist on their actual screen).
Suggested next steps for investigation
Consider giving the model an accurate, surface-specific inventory of what feedback/
UI controls actually exist on the current surface (tying into the same
"which client am I on" gap from Item 2), so answers like this can be accurate
rather than generalized from other surfaces.
Alternatively, reinforce (via system prompt or training) that claims about specific
UI elements the model cannot directly observe should be hedged rather than stated
as fact, especially for surface-specific details like button placement.
Compiled from direct observation during a live session at the user's request, to be
submitted as user feedback to Anthropic. Not an official Anthropic engineering
document. More items may be appended as they come up.
What Should Happen?
Claude should know the picture is as he requested on desktop like he does on mobile.
Claude should know whether you're on mobile or desktop, instead of guessing (wrong).
Claude should not believe there are thumbs up/down on either his current desktop or current mobile app, and he agrees with me all the way around.
I'm a more basic vibe coder, so this might help you.
Error Messages/Logs
Steps to Reproduce
Feel free to read our convo.
Claude Model
Sonnet (default)
Is this a regression?
No, this never worked
Last Working Version
No response
Claude Code Version
Most recent update, 7.12.26 10:17 PM EST
Platform
Anthropic API
Operating System
Windows
Terminal/Shell
Other
Additional Information
I'm just using the desktop app and the mobile app. That's all I ever use with Claude Code.
Preflight Checklist
What's Wrong?
CLAUDE TOLD ME TO SEND THIS.
Session UX Feedback for Anthropic
A running list of small usability/self-awareness gaps noticed during a live Claude
Code session, compiled at the user's request so they can pass them along as feedback.
None of these are the model's "fault" in any meaningful sense — they're gaps in what
information the surrounding product actually gives the model to work with.
Item 1: File attachments from Claude Desktop app not reaching the session's filesystem
Summary
Images attached via the Claude Desktop app's file-attach control appeared normally in
the conversation UI (rendered visually, described accurately by the model) but never
arrived as an actual file the backend session could access. The same attachment action
performed moments later from the Claude mobile app worked correctly on the first try.
This makes any tool-based processing of the image (resizing, cropping, saving as a
project asset, etc.) impossible when attaching from the affected Desktop build, even
though the user sees no error and the image displays fine in the chat.
Environment
Client where the bug occurred: Claude Desktop app, per the user "since the
[most recent] update" — exact version unknown, but the user notes the same update
otherwise improved stability ("you ordinarily would have crashed several times by
now for me on this weak little laptop").
Client where it worked correctly: Claude mobile app (same account, same
conversation, immediately after).
Underlying environment: Claude Code session (remote/cloud execution), where
attachments are expected to be saved server-side to a per-session uploads directory
and surfaced to the model via an internal Read-tool call.
Steps to reproduce (as observed)
In an ongoing Claude Desktop conversation, use the attach-file / paperclip control
to attach an image (not drag-and-drop, not paste — the user confirmed they used the
dedicated attach button both times).
Send the message.
The image renders normally in the conversation thread for the user, and the model
receives and can visually describe the image's contents.
Expected: the file is saved to the session's uploads directory and a
Read tool call system-reminder appears referencing its path, exactly as it does
for every other successful attachment in the session — making the file available
to shell/file tools.
Actual: no such system-reminder appears, and no new file is created anywhere
under the session's writable filesystem within several minutes of the message being
sent (confirmed via a filesystem-wide search for recently modified image files).
The model has only the rendered/visual representation of the image in context, with
no backing file — any attempt to read, copy, or process it via file tools fails
because there is nothing on disk to point to.
Evidence gathered during the session
Two separate images were attached this way, in two separate messages, from the
Desktop app. Neither produced a file in /root/.claude/uploads//, and
neither was preceded by a "Called the Read tool" system-reminder (the pattern every
other attachment in the session produced).
A third image, sent immediately after via the Claude mobile app, succeeded
immediately: it appeared as /root/.claude/uploads//d6590e5a-1000001658.webp
with the expected system-reminder, and was fully readable/processable.
The user independently confirmed they used the same attach-button workflow both
times on Desktop, ruling out user error (e.g., accidentally pasting instead of
attaching) as the cause on at least the second attempt.
Impact
Silent failure mode: the user receives no error, warning, or visual difference
between a successful and failed attachment. The only symptom is that the model's
downstream actions (e.g., "resize this image and add it to the file") can't
actually be carried out, and the user has to notice that nothing changed.
This is especially misleading in agentic/tool-using contexts (like Claude Code),
where the user reasonably expects an attached file to be operable by shell/file
tools once it appears in the chat.
Suggested next steps for investigation
Compare the upload code path between the affected Desktop build and the mobile
app build to find where the file fails to be persisted/forwarded to the session
environment.
Consider surfacing an explicit error/toast in the Desktop client if an attachment
fails to reach the backend, rather than only rendering it client-side.
If this is a regression from a recent Desktop release, a version bisect against
that release would likely narrow it down quickly given how reproducible it was here
(2/2 failures on Desktop, 1/1 success on mobile, same account, same conversation).
Item 2: The model has no reliable way to know which client (mobile vs. desktop) the user is currently on
Summary
While troubleshooting Item 1, the model repeatedly had to guess or take the user's
word for which app they were using (Desktop vs. mobile), because nothing in the
session context reliably identifies the originating client on a per-message basis.
This led directly to a wrong assumption: the model told the user to try the
"attachment/photo picker button" as if switching away from pasting would fix things,
when the user was in fact already using that exact control on Desktop — the model's
guess about what the user was doing was downstream of not actually knowing which
client they were on.
Why this matters
The model can currently only infer client/device from indirect, unreliable signals:
the user's own statements ("I'm on desktop today"), or circumstantial evidence like
whether an attached file happens to land on disk. Neither is something the model
should have to rely on for a fact the surrounding product almost certainly already
knows at the infrastructure level (which app/platform sent the request).
This isn't just a convenience issue — it's a self-awareness gap. A model that is
asked "am I on your desktop or phone right now?" should be able to answer from
session metadata, the same way it can already tell working directory, git branch,
or platform/OS. Right now it can't, so it either guesses or has to ask.
One session-level field (an "entrypoint" value suggesting the session originated
from mobile) was visible in the underlying transcript file, but this is (a) not
something exposed to the model as a normal, documented field it should rely on, and
(b) session-level rather than per-message, so it wouldn't have reflected the
mid-session switch to Desktop and back to mobile that actually happened here.
Suggested next steps for investigation
Expose a lightweight, per-message (or per-turn) "client" field to the model in the
same way other environment facts are surfaced (e.g. alongside working directory /
platform info), so the model can answer this correctly without asking, and can
reason accurately about client-specific quirks (like Item 1) as they arise.
If a stable per-message signal isn't feasible, even a session-level "current client"
value that updates when the user switches apps would be an improvement over the
static, undocumented field currently only visible by inspecting internal transcript
files directly.
Item 3: The model asserted a UI feature (thumbs up/down feedback buttons) that doesn't exist in Claude Code
Summary
When asked how to submit Item 1 as feedback, the model suggested using "in-app
feedback (thumbs-down / 'Report a bug' on the relevant message)" as the most direct
route. The user, working in Claude Code, corrected this: no such buttons exist in
that surface. The model was speaking from general familiarity with feedback controls
that exist on other Claude surfaces (e.g. claude.ai) without being certain they apply
to Claude Code specifically, and stated it as fact rather than flagging the
uncertainty.
Why this matters
This is the same root shape as Item 2: the model doesn't have a reliable way to
know exactly which UI affordances are present on the specific surface the user is
currently using, so it fills the gap with a plausible-sounding but unverified
assumption instead of either checking or saying "I'm not sure this exists on this
surface."
Low stakes here (the user just corrected it and moved on), but the same failure
mode — confidently describing a UI element the model can't actually see or verify —
could be more costly in other contexts (e.g. walking a user through steps that
don't exist on their actual screen).
Suggested next steps for investigation
Consider giving the model an accurate, surface-specific inventory of what feedback/
UI controls actually exist on the current surface (tying into the same
"which client am I on" gap from Item 2), so answers like this can be accurate
rather than generalized from other surfaces.
Alternatively, reinforce (via system prompt or training) that claims about specific
UI elements the model cannot directly observe should be hedged rather than stated
as fact, especially for surface-specific details like button placement.
Compiled from direct observation during a live session at the user's request, to be
submitted as user feedback to Anthropic. Not an official Anthropic engineering
document. More items may be appended as they come up.
What Should Happen?
Claude should know the picture is as he requested on desktop like he does on mobile.
Claude should know whether you're on mobile or desktop, instead of guessing (wrong).
Claude should not believe there are thumbs up/down on either his current desktop or current mobile app, and he agrees with me all the way around.
I'm a more basic vibe coder, so this might help you.
Error Messages/Logs
Steps to Reproduce
Feel free to read our convo.
Claude Model
Sonnet (default)
Is this a regression?
No, this never worked
Last Working Version
No response
Claude Code Version
Most recent update, 7.12.26 10:17 PM EST
Platform
Anthropic API
Operating System
Windows
Terminal/Shell
Other
Additional Information
I'm just using the desktop app and the mobile app. That's all I ever use with Claude Code.