ProviderService.followUp never builds the [Attached … is saved at: …] path
lines that sendTurn builds — attachmentPathLines exists only in sendTurn.
Since #140, every adapter except OpenCode deliberately skips non-image
attachments and relies on that path line to tell the agent the file exists. On
the follow-up path there is no path line, so a generic file attached to a queued
follow-up is dropped entirely: not ingested natively, not surfaced as a path.
The agent never learns it exists, and nothing errors.
Not yet reachable, but it will be
No client can attach a generic file until upstream #8236 (web picker) and
#8237 (mobile picker) land, both still open. This should be closed before
those ship rather than after, because the failure is silent.
Inherited rather than introduced: upstream's ProviderService has the same
shape, with attachmentPathLines only in sendTurn.
Found during the independent review of #140; recorded in
.agents/upstream-review.md.
ProviderService.followUpnever builds the[Attached … is saved at: …]pathlines that
sendTurnbuilds —attachmentPathLinesexists only insendTurn.Since #140, every adapter except OpenCode deliberately skips non-image
attachments and relies on that path line to tell the agent the file exists. On
the follow-up path there is no path line, so a generic file attached to a queued
follow-up is dropped entirely: not ingested natively, not surfaced as a path.
The agent never learns it exists, and nothing errors.
Not yet reachable, but it will be
No client can attach a generic file until upstream
#8236(web picker) and#8237(mobile picker) land, both still open. This should be closed beforethose ship rather than after, because the failure is silent.
Inherited rather than introduced: upstream's
ProviderServicehas the sameshape, with
attachmentPathLinesonly insendTurn.Found during the independent review of #140; recorded in
.agents/upstream-review.md.