2026 DeepSeek Harness Image Attachment Acceptance

DeepSeek Harness is still a developer preview. The official repository warns that compatibility-breaking changes are expected. The v0.1.0-rc.7 release added durable image attachments for MCP and ACP, plus nested image forwarding in PTC Mode. Those are implementation capabilities, not automatic proof that every model endpoint can process images. (github.com)

The acceptance decision should therefore use three outcomes:

• Pass: the complete path works after the required restart or recovery test.
• Limited: the attachment survives or travels through part of the path, but the selected model, child route, or recovery behavior is not reliable.
• Reject: the image is only visible in the interface, disappears before the model request, reaches the wrong task, or causes an unsafe replay loop.

The key distinction is simple:

Harness support, Provider support, and upstream model support are three different claims.

A custom Provider can declare image input in its settings. That declaration may allow an attachment control to appear. It does not prove that the upstream endpoint accepts an image content part, preserves the binary asset, or returns a vision-based answer.

The current official DeepSeek Chat Completions schema documents user message content as text content, while the official integration guidance describes DeepSeek V4 as text-only and uses another model as an image-description proxy for screenshot workflows. Check the current endpoint documentation before approving a visual workflow. (api-docs.deepseek.com)

The first acceptance gate is the model capability check. Do not infer image support from a model name, a model badge, or a file picker.

Use this sequence:

1. Open the active model and Provider configuration.
2. Record the declared input modalities.
3. Capture the interface behavior when an image is attached.
4. Inspect the outgoing request or request trace.
5. Record the upstream response.
6. Repeat with a known text-only route if the workflow supports fallback.

The evidence should answer four questions:

• Did the selected route declare image input?
• Did the request contain an image reference or image content part?
• Did the upstream endpoint accept that representation?
• Did the answer use a detail that exists only in the image?

A successful text response is not enough. A model may answer from the task description, cached context, or a previous turn. Use a test image with a unique label, a distinct color, and one deliberately small detail. Ask for all three. The answer should prove that the image was read rather than merely acknowledged.

The model capability gate fails when:

• the interface blocks the attachment before submission;
• the request is converted to a local path without a supported reader;
• the upstream endpoint returns an unsupported content error;
• the response describes only the prompt;
• the Provider says “vision supported” but the endpoint rejects the image.

DeepSeek’s official API documentation should be the authority for the active route. The current Chat Completions schema lists supported request fields and model identifiers. The official agent integration guidance also shows why an integration can accept a screenshot while using a separate vision model to describe it before sending text onward. (api-docs.deepseek.com)

Once model capability is clear, test whether the correct asset reaches the request.

Use two or three synthetic images. Avoid customer screenshots, production repositories, access tokens, and personal data. Each image needs a visible identifier such as RED-ALPHA, BLUE-BETA, or GREEN-GAMMA. The identifier is for the test operator, not for the production workflow.

Check these transport properties:

• attachment order;
• filename or attachment identifier;
• task text associated with each image;
• image-to-response correspondence;
• duplicate references;
• missing references;
• conversion or resizing behavior;
• failure location.

Do not accept a test because the upload icon changes state. Do not accept it because a thumbnail remains on screen. The thumbnail may be a browser object, a cached preview, or a local UI state that never enters the model request.

A transport pass requires a trace showing the same attachment identity at the handoff boundary and at the receiving boundary. If the system redacts binary content from logs, record a safe identifier and a cryptographic hash instead. The hash does not prove that the model saw the image, but it helps prove that the intended asset was carried through the chain.

For MCP and ACP paths, separate the checks:

• MCP: verify the tool or server response contains the attachment reference expected by the receiving task.
• ACP: verify the protocol message, session mapping, and receiving Provider preserve the same attachment identity.
• Direct Web workflow: verify the browser submission and the model request are linked by one trace identifier.

A mismatch should be classified by node. The sender may have produced the right asset. The transport layer may have dropped it. The receiving Provider may have ignored it. The model may have rejected it. Assigning all failures to “the model” hides the repair.

The second major boundary is persistence. “The file is still visible” can mean three different things:

1. the interface still has a cached preview;
2. the session transcript stores an attachment reference;
3. the underlying asset is available and can be read again.

Only the third state proves that the visual task can continue.

Run the persistence test in stages:

1. Send a text-plus-image task and save the response.
2. Refresh the Web UI.
3. Reopen the same session.
4. Disconnect and reconnect the client.
5. Restart the harness process.
6. Reissue a new question that depends on the old image.
7. Compare the attachment identifier and the model request.

Use a question that cannot be answered from the transcript alone. For example, ask for the small marker in the lower-right corner, not the general subject of the screenshot.

Record these artifacts:

• session identifier;
• attachment identifier;
• asset hash;
• transcript entry;
• storage path or storage service reference;
• permission result;
• request trace after recovery;
• final model response.

A persistence failure occurs when the transcript says an attachment exists but the recovered task cannot read it. It also occurs when the UI displays a stale thumbnail while the backing file has been deleted or permission-restricted.

The rc.7 release confirms durable image attachments for MCP and ACP. It does not remove the need to test the storage layer, permission model, or selected Provider. The release also includes fixes for session continuity after token truncation, but that is not the same as proving every image-bearing session can resume safely. (github.com)

Operational reminder: never describe a remote Mac as automatically persistent or isolated. Confirm where attachments, session files, logs, and temporary files live, who can read them, and what survives handover.

Nested tasks need their own acceptance gate. A parent task can display an image correctly while a child task receives only the text description, the wrong attachment, or no attachment at all.

Build a parent-child test with different visual facts:

• Image A contains a large red square and the label PARENT.
• Image B contains a small blue triangle and the label CHILD.
• The parent task must inspect Image A.
• The nested task must inspect Image B.
• The final response must identify which task saw which detail.

This prevents a false pass caused by one shared image or a generic answer.

For PTC Mode, record:

• parent task identifier;
• child task identifier;
• attachment identifiers at both levels;
• parent request trace;
• child request trace;
• child response;
• final aggregation response.

The official rc.7 release states that PTC Mode can forward nested images. The acceptance question is narrower: did the intended child receive the intended original image through the actual Provider route? (github.com)

Classify failures by responsibility:

• Parent preparation failure: the parent never attached or selected the intended image.
• Forwarding failure: the child task was created without the attachment reference.
• Provider failure: the child route dropped or transformed the image.
• Model failure: the child received the image but could not interpret it.
• Aggregation failure: the child result was correct but the parent reported it incorrectly.

Do not use a screenshot of the Job Panel as the only proof. The task trace and receiving result are stronger evidence.

Image workflows create a specific recovery hazard. If the upstream model rejects an image but the harness marks the turn as pending, restoring the session may replay the same request. That can create duplicate uploads, repeated failures, or a loop that looks like a transport problem.

Test three recovery states:

1. image accepted and response completed;
2. image rejected before a final response;
3. process interrupted during upload or model execution.

For each state:

• stop the client or process;
• restore the old session;
• inspect the pending turn;
• observe whether the image is sent again;
• check whether the request identifier changes;
• confirm whether the assistant response is duplicated;
• apply a safe fallback.

The fallback should be explicit:

• remove the attachment and retry with text evidence;
• switch to a Provider with verified image input;
• create a new session;
• preserve the original failed trace for debugging.

A recovery pass requires more than “the conversation reopened.” The restored session must avoid unsafe duplication and must preserve enough context for the operator to make a clear next decision.

The official repository describes session-oriented architecture, while the rc.7 release includes a fix for preserving sessions after max-token truncation. Treat those as useful implementation signals, not as substitutes for a recovery test with an actual image rejection. (github.com)

Remote execution adds storage, access, and handover responsibilities. It does not solve them automatically.

On the remote Mac, verify:

• the attachment asset exists at the expected location;
• the session file points to the correct asset;
• the running user has read permission;
• the next operator can reopen the session;
• the asset is not stored only in a temporary directory;
• logs do not expose secrets or customer content;
• the same test can be repeated after disconnecting the original operator.

Use a redacted evidence package. Include identifiers, hashes, timestamps, model and Provider names, protocol path, and pass or fail results. Exclude API keys, cookies, customer repositories, private screenshots, and unredacted environment files.

If the team uses a temporary remote environment, define the retention boundary before testing. Decide what is copied to team storage, what is deleted at teardown, and who is allowed to restore the session.

Teams comparing local workstations with remote delivery should also review the DeepSeek Harness cloud Mac delivery acceptance workflow. The relevant question is not whether the Mac is online. It is whether another operator can reproduce the same attachment read, session restore, and evidence handover without relying on the original operator’s browser cache.

Use this checklist for each model, Provider, and protocol combination. One unchecked item means the route is not ready for unrestricted visual work.

• [ ] The selected model explicitly declares image input support.
• [ ] The Provider declaration matches the actual upstream endpoint.
• [ ] A synthetic image with unique visual markers was used.
• [ ] The request trace proves the intended attachment entered the route.
• [ ] The response identifies a detail that exists only in the image.
• [ ] Attachment order was tested with more than one image.
• [ ] MCP delivery was tested separately from direct Web delivery.
• [ ] ACP delivery was tested separately from MCP delivery.
• [ ] The session was checked after a page refresh.
• [ ] The client was disconnected and reconnected.
• [ ] The harness process was restarted.
• [ ] The recovered task could read the original asset again.
• [ ] A PTC Mode parent task forwarded the intended image to the child.
• [ ] The child result was checked against a child-only visual detail.
• [ ] An upstream image rejection was tested.
• [ ] Recovery did not create an unsafe duplicate request loop.
• [ ] A text-only fallback or new-session fallback was documented.
• [ ] Remote Mac permissions were checked with the handover account.
• [ ] Temporary storage and retention behavior were documented.
• [ ] Evidence was redacted before team sharing.
• [ ] The final status was marked Pass, Limited, or Reject.

The practical release decision is not “does the upload control work?” It is “which workflow is safe to authorize?”

By the end of the first test session, create one blank acceptance record and run the same synthetic image through the selected model, MCP or ACP path, PTC Mode, and recovery flow. Do not approve production screenshots until the record contains a request trace, a post-restart read result, and a replay decision.

If the route fails only because the current upstream endpoint is text-only, switch to text evidence or a verified vision model. Do not convert a Provider declaration into a capability claim.

For teams using a temporary remote Mac, MESHLAUNCH can be useful when the goal is a controlled environment for a short validation cycle, team handover, or repeatable UI evidence capture. A self-managed Mac remains the better fit for long-running workloads, fixed hardware access, or requirements that depend on permanent local storage. Before choosing a remote setup, review the available Mac environment options and treat storage, access permissions, and session recovery as separate acceptance items.

The important comparison is concrete: a local setup can keep assets close to the operator but may leave recovery, access control, and handover undocumented. A generic remote setup may provide connectivity but still lose temporary files, preserve only browser state, or expose unclear ownership of session records. Renting a controlled Mac environment through MESHLAUNCH is the more practical option when the work is temporary and the team needs a clean place to run, verify, and hand over image-bearing DeepSeek Harness workflows. It is not a replacement for a permanent workstation when the same assets must remain available indefinitely.

For the next step, use the blank checklist in a separate remote environment, then compare the evidence package with the requirements in the remote Mac delivery acceptance guide.