Sending Screenshots to Claude Code and Codex: What AI SDK Image Inputs Change

As of Vercel’s 2026-10-27 changelog, developers routing work through the AI SDK’s HarnessAgent layer can attach screenshots to a coding-agent task using the same message format for every harness adapter, including Claude Code and Codex. If you maintain a harness that fans work out to Claude Code, Codex, Cursor, GitHub Copilot, or Cline, the practical consequence is direct: the multimodal-input question moves from “which adapter accepts images?” to “which adapter actually reads my screenshots well, at what cost, and under what sandbox behavior?” The first question is now answered at the layer level, at least according to the vendor. The second is not, and everything below hangs on that distinction.

What changed in the message format

The changelog states the feature plainly: “The AI SDK HarnessAgent layer now accepts image inputs across every harness adapter.” Images travel as file parts inside the standard AI SDK content array, mixed with text parts:

“Pass images alongside text in the standard AI SDK message format: a content array mixing { type: ‘text’ } and { type: ‘file’ } parts.”

File parts carry a mediaType such as 'image/png' plus the raw data, with the documented example reading a local file via readFileSync('image.png'). If you already build AI SDK messages as content arrays, a screenshot is one more part in the array, not a new API surface.

The sandbox wiring is worth noting: it is the kind of detail that can break a harness integration. The documented example wires the Codex harness through @ai-sdk/harness-codex, creating a Vercel network sandbox session with runtime: 'node24', ports: [4000], and a template obtained from the agent itself:

const agent = new HarnessAgent({ harness: codex });
const sandboxSession = await createVercelNetworkSandboxSession({
  runtime: 'node24',
  ports: [4000],
  template: await agent.getSandboxTemplate(),
});
const session = await agent.createSession({ sandboxSession });

The important detail is agent.getSandboxTemplate(): the sandbox template comes from the adapter, not from your own configuration. That means the adapter controls the environment your screenshot-driven session runs in, and two adapters can accept the identical message while provisioning different sandboxes. When you validate adapters, the sandbox is part of what you are testing, not just the model.

The ten adapters, and what “supported” means

The vendor-stated list, quoted from the changelog: “Claude Code, Cline, Codex, Cursor, Deep Agents, fx, GitHub Copilot, Grok Build, OpenCode, Pi.” Image input is, per the same source, “processed by the harnesses’ underlying vision models.”

That last clause does the real work. “Supported” here means the harness layer will accept a file part and route it to the underlying model. It does not mean the underlying model interprets a UI screenshot accurately, and no independent test of image understanding for any of the ten adapters appears in the changelog or the research reviewed here. Treat the entire list as vendor-stated capability, not measured behavior.

The table is thin on the right side by design. That thinness is the finding: acceptance is uniform and documented; quality is unmeasured in the sources reviewed here.

Adapters are not interchangeable, and direction matters

The strongest independent evidence does not concern images at all, which is exactly why it matters. A controlled cross-model review study on 116 hard and medium LiveCodeBench tasks, arXiv:2607.21656, measured what happens when one coding agent reviews another’s drafts. Claude Opus 4.7 reviewing Codex GPT-5.5 drafts raised the pass rate from 71.6% to 89.7% (p_BH=.001), per arXiv:2607.21656, and Codex GPT-5.5 self-review raised it to 84.5% (p_BH=.022). The reverse pairing went the other way:

“The reverse direction does not pay off: Codex GPT-5.5 reviewing Claude Opus 4.7 drafts drops the pass rate from 91.4% to 82.8% (p_BH=.046).” (arXiv:2607.21656)

Same task set, same review step, opposite outcome depending on which model sits in which seat. If text-only code review shows this much asymmetry between the two adapters your title cares about, there is no reason to assume their vision models interpret the same error-dialog screenshot equivalently. The study’s authors pin their results to specific model identifiers, CLI versions, and execution dates, and caution that future releases may shift the numbers in either direction.

The inference I would draw, and it is an inference: uniform image acceptance at the harness layer does not imply uniform image understanding underneath it. The harness now normalizes the input format. It does not normalize what happens after.

Input quality still does more work than the image

Attaching a screenshot does not exempt the task from the framing disciplines that already predict agent outcomes. For Copilot-style coding agents, a study of what makes an issue ready for the agent, arXiv:2512.21426, found that restricting task scope increased pull-request acceptance chances by 13%, and that titles up to 20 words raised merge probability from 47% to 60% (per arXiv:2512.21426), plateauing in the 0.58–0.62 range beyond that.

The analogous practice for screenshot triage: send the image plus a tight text part that states the scope, the expected behavior, and the observed behavior. A bare PNG of an error dialog hands the model a guessing problem; the same PNG with two sentences of root-cause context hands it a debugging problem. The screenshot adds reproduction evidence the text cannot carry, but the text still carries the framing. No independent measurement of screenshot inputs appears in the sources reviewed here, so treat this as a reasoned transfer, not a measured result.

What a vision step costs

No image-token pricing appears in the changelog or in the research cited here. The one concrete cost figure available is from the cross-model review study, and it is a text-code-review number: reproducing all six writer-reviewer conditions across the 116 tasks cost roughly $225 in API calls, about $1.94 per task, per arXiv:2607.21656. The authors attach a warning that applies to every number in this article:

“Cost figures are point-in-time estimates subject to pricing and caching changes.”

The transferable lesson is structural, not numerical. A screenshot-driven step is an extra model call carrying image tokens on top of text tokens, adding latency as well as spend, and the study treats pass rate, cost, latency, fixes, and regressions as a measurement set rather than any single number. Before standardizing on an adapter for vision-dependent triage, price the step yourself on your own screenshots; neither the changelog nor the research cited here can do it for you.

One more caution, from a different domain. A simulation framework for AI triage in clinical imaging, arXiv:2510.27104, models multi-AI, multi-disease reading workflows in which an AI prioritizes some conditions and no AI exists for the rest; its estimates split into mean wait-time savings for the conditions an AI identifies and delays for the conditions without one. Clinical imaging is not coding, and this is a cross-domain analogy, not evidence about your queue. But the shape of the risk transfers: if screenshot triage handles the bug classes your adapter reads well, the bugs it reads poorly do not disappear, they wait. Measure the redistribution, not just the average speedup.

Per-adapter friction the harness will not hide

Uniformity at the harness layer can mask availability and integration differences underneath. The clearest practitioner evidence covers GitHub Copilot. In a 2023 empirical study of Copilot limitations, arXiv:2303.08733, difficulty of integration was the most-cited of 15 limitations at 28.0%, ahead of poor code quality (11.6%) and privacy concerns (7.5%). A larger follow-up, arXiv:2309.05687, put integration difficulty at 28.1% of reports and documented growing subscription friction, including free-tier users hitting rate limits with, as one user put it, “no way out.”

Both studies are from 2023 and may not describe the current Copilot adapter; treat that as an open question rather than a settled one. The durable point is that a harness-level support check does not tell you whether a given adapter’s IDE integration, plan tier, or rate limits will survive your workload. That is a per-adapter validation item, not a reason to distrust the harness.

What to test before trusting an adapter with screenshots

Given the evidence, the validation checklist for each adapter you intend to use on vision-dependent steps:

1. Image understanding on your own artifacts. Run a fixed set of your real screenshots (UI bugs, error dialogs, design diffs) through each candidate adapter and score the responses by hand. No independent measurement of this appears in the changelog or the research reviewed here.
2. Sandbox behavior. The template comes from agent.getSandboxTemplate(), so confirm what runtime and ports each adapter provisions and whether your reproduction steps actually execute there.
3. Cost and latency per triage step. Measure tokens and wall time on your workload; treat any published figure, including the $1.94-per-task figure from arXiv:2607.21656, as point-in-time and text-only.
4. Pairing direction, if you chain agents. If a second agent reviews the first’s screenshot-driven fix, test both directions; the measured asymmetry says order can flip the outcome.
5. Access and rate limits. Confirm your plan tier sustains the volume, especially for Copilot given the practitioner reports.

The verdict, and its limits

Build screenshot intake at the HarnessAgent layer using content arrays that mix { type: 'text' } and { type: 'file' } parts. The format is documented, the adapter list is named, and teams that previously picked a harness partly for multimodal input can stop doing that. I would wire the intake once, at the layer, and spend the saved effort on per-adapter evaluation instead.

But hold the verdict to its evidence. Everything about image support rests on the vendor changelog alone. No independent measurement of image understanding for any adapter appears in the sources reviewed here, image-token pricing is absent, sandbox equivalence across adapters is untested, and the strongest independent evidence, the cross-model review study, is text-only and pinned to specific model and CLI versions. “Supported across all ten adapters” is a statement about message routing. Whether any adapter deserves your vision-dependent QA steps is a question only your own screenshots can answer.

Frequently Asked Questions

How do you attach an image to a HarnessAgent task?

Pass images alongside text in the standard AI SDK message format: a content array mixing { type: ‘text’ } and { type: ‘file’ } parts.

Where does the sandbox template for a harness session come from?

The important detail is agent.getSandboxTemplate(): the sandbox template comes from the adapter, not from your own configuration. That means the adapter controls the environment your screenshot-driven session runs in, and two adapters can accept the identical message while provisioning different sandboxes.

Does the changelog provide pricing for image tokens?

No image-token pricing appears in the changelog or in the research cited here. The one concrete cost figure available is from the cross-model review study, and it is a text-code-review number: reproducing all six writer-reviewer conditions across the 116 tasks cost roughly $225 in API calls, about $1.94 per task, per arXiv:2607.21656.