DeepSeek Harness: GIF first frame, Android EACCES upload

DeepSeek Harness (DSH) has two image-and-attachment problems that are especially easy to misjudge, and their directions are exactly opposite: one is "information got dropped but nobody says so"—read_image accepts an animated image, but hands the model only the first frame, and the result mentions neither the frame count nor any note, so the model describes the animation as a still image; the other is "an environment precondition is unmet but the error is very short"—in a restricted environment like an Android app sandbox, attachment upload always fails, reporting EACCES: permission denied, open '/data/user/0', because the attachment durable-directory sync walks all the way up to the filesystem root, and the upper directories give an ordinary app only execute, not read. The former should be handled as a contract plus an observability gap ("first frame only" is documented; what is missing is the "notice"), and the latter should be worked around by path boundary (changing the data directory) or left to the fix (skip on a permission error) (#8793, #9247).

DSH plugin GIF first frame only: dropping frames is the contract, not telling is the defect

One-line conclusion: read_image accepts an animated image by sniffing the file header, but attachment normalization re-encodes it into a single static image, keeping only the first frame—the frame count is already lost before the model sees it; and the result carries neither a frame count nor a text note, so the model uses the animation as if it were a still. (#8793)

DSH plugin diagnosis and position: don't blend two things into one

This point matters, because it decides what you should report (#8793):

So the correct feedback position is: the result should carry the original frame count and the tool description should explain the animated-image behavior, not "why are frames dropped" (#8793).

DSH plugin three-step confirmation and handling

1. Confirm the diagnosis: have the agent read an obviously moving animated image and watch it describe "a static picture"; at the same time check whether the tool return has any frame count or note—both true together is this entry (#8793).
2. User-side workaround (recommended, least effort): extract frames from the animation yourself and tile them into one contact sheet before handing it to read_image:

# Extract several key frames and tile them horizontally into one static image (illustrative)
ffmpeg -i anim.gif -vf "fps=1,scale=320:-1,tile=4x3" -frames:v 1 contact-sheet.png

That way the model sees an image that packs multiple frames of information into one frame, preserving an overview of the motion and avoiding the "the model thinks this is a still" misunderstanding (#8793).

3. Upstream fix (two small points): when the source file has more than one frame, include the frame count in the returned result (for example originalFrames: 3), and add a line about the animated-image behavior in the tool description (#8793).
4. Verify: after extracting frames, rerun and confirm the model can describe multiple stages of motion; if it still describes a still, check whether the tiled image was compressed too much to show the differences (#8793).

DSH plugin attachment always fails in an Android restricted environment: the sync walks all the way to the filesystem root

One-line conclusion: to guarantee that attachments land durably, the attachment module syncs level by level upward from the data directory all the way to the filesystem root; in an Android app sandbox the upper directories (such as /data/user/0) give an ordinary app only execute, not read, so opening them read-only always fails—and the whole attachment write flow aborts there. The error is EACCES: permission denied, open '/data/user/0', while plain-text sessions work perfectly (#9247).

DSH plugin diagnosis: two contrasts pin it down immediately

1. "Text fine, only attachments fail": it means this attachment path has an extra precondition, while the network and credentials are fine (#9247).
2. The failing path is the filesystem root or a parent of the data directory, not your workspace: this is the fingerprint of this entry—if the failing path were inside the workspace, it would be a different class of permission problem (#9247).
3. Note this is not Android-specific: the discussion states plainly that the behavior also holds on other similarly restricted filesystems (as long as an upper directory is not readable by the process), so the investigation approach generalizes (#9247).

DSH plugin three-step handling

1. Change the data directory (user-side workaround): put DSH's data directory on a path the app itself can read and write, avoiding a case where an upper directory is not readable (#9247).
2. Fix direction (a patch given and tested in the discussion): make the sync step skip rather than abort on EACCES / EPERM; the premise is that the directory is not writable (keep that premise—otherwise the durability guarantee is weakened) (#9247).
3. Verify: rerun the same image attach operation; expect no more EACCES, and reading the attachment afterward works (#9247).
4. Also remember: the test expectations include assertions about "which directories need to be synced", so they must be updated too when you change this (the knock-on work the discussion mentions) (#9247).

DSH plugin troubleshooting notes

This family has only two members, but their directions are completely different: one is "missing information", the other is "an environment precondition". First check whether there is an error, then decide which way to think. Seven points:

1. No error, just a wrong description → investigate toward "missing information" (the animated-image entry) (#8793).
2. An EACCES with the path at the filesystem root → investigate toward "environment precondition" (#9247).
3. "Text fine, attachments fail" is a very strong scope limiter; use it first (#9247).
4. Don't report the animated-image entry in the wrong direction: the contract itself is fine; what is missing is the "notice" (#8793).
5. Frame extraction and tiling is the most practical user-side move, faster than waiting for the fix (#8793).
6. The premise for skipping the sync is "the directory is not writable"; don't loosen the durability guarantee just to get around the error (#9247).
7. State the fix status honestly: both are unfixed in the versions the discussions refer to; the animated-image entry is "documented behavior plus an observability gap", and the reporter's patch for the attachment entry is not merged, so for now only user-side workarounds like changing the directory exist.

When investigating attachment and image problems, the "environment" layer often decides the conclusion—especially where the data directory lives. If you would rather see the plugin and log layer clearly first, instead of typing commands everywhere, use a visual plugin marketplace such as DSH Plugin Hub: the installed list, install/uninstall history, and system logs are all in one panel.

Source: Discussion #8793, Discussion #9247.