[FEATURE] Add option to disable automatic image processing on paste to support user-controlled image pipelines

Resolved 💬 2 comments Opened Apr 3, 2026 by mayankmahavar111 Closed Apr 3, 2026

Preflight Checklist

  • [x] I have searched existing requests and this feature hasn't been requested yet
  • [x] This is a single feature request (not multiple features)

Problem Statement

Problem Statement

Currently, pasting an image into Claude Code triggers automatic processing and interpretation. There is no way to disable this behavior or intercept the image before Claude analyzes it.

This acts as a strict blocker for users who need to own the image processing pipeline—specifically, using a local vision model to extract structured data from an image in a strict format, and then driving downstream actions from that output. Claude's default auto-processing is too opinionated and unstructured for this use case.

What Happens Today (Unwanted Workflow)

  • User pastes an image.
  • Auto-Trigger: Claude automatically interprets it (cannot be stopped).
  • Result: Unstructured description populates the chat.
  • Conflict: If the user then tries to run a custom /image-processing command, it is redundant; Claude has already "seen" the image, resulting in conflicting local vs. cloud interpretations.

What the User Wants (Desired Workflow)

  • User pastes an image.
  • Attachment Only: Image attaches as [Image #N] with NO auto-processing.
  • Custom Invocation: User invokes /image-processing [Image #1].
  • Local Routing: Request routes to a local model (e.g., Gemma 3 4B via LM Studio coordinator).
  • Structured Output: Local model returns a controlled, user-defined format:

``json
{
"extracted_text": "...",
"ui_elements": [...],
"errors": [...],
"actions": [...]
}
``

  • Downstream Action: User drives next steps exclusively from this structured data.

Why This Matters

The goal is not simply to "skip" Claude's analysis, but to replace it entirely with a purpose-built extraction pipeline. Key requirements:

  • Extract highly specific data from the image.
  • Structure the output in a controlled, predictable format.
  • Decide programmatic next steps based on that structured output.

A local vision model with a custom prompt can guarantee structured, actionable data—but only if Claude does not preemptively process the image first.

Real-World Example

A custom /image-processing slash command routes images through a local Gemma 3 4B vision model via an LM Studio coordinator. It accepts image paths plus a custom prompt, returns structured analysis, and tracks token usage.

Desired action after pasting the image:

/image-processing [Image #1] --prompt "Extract all error messages and suggest fixes"

```json
{
  "errors": [
    "NullPointerException at line 42",
    "Unhandled promise rejection"
  ],
  "suggestions": [
    "Check null guard at AuthService.ts:42",
    "Add .catch() to fetchUser()"
  ]
}

Proposed Solution

Proposed Solution

Two options — either would solve the problem:

Option A: autoProcessImages Setting

(Lowest friction, most backward-compatible)

// ~/.claude/settings.json
{
  "autoProcessImages": false
}

### Alternative Solutions

### Option B: Image Token as Slash Command Argument
*(More powerful)*

Allow `[Image #N]` tokens to be passed as arguments to custom slash commands:
```bash
/image-processing [Image #1] --prompt "Extract errors"
  • Invocation-Time Resolution: CLI resolves [Image #N] references at command invocation time.
  • Data Handoff: Passes raw image data or a temp file path into {{ARGUMENTS}}.
  • First-Class Pipeline: Unlocks a first-class custom vision pipeline.
  • No Side Effects: Prevents auto-processing side effects.

Option C: PreImagePaste Hook

(Most extensible, fits existing hook model)

// ~/.claude/settings.json
{
  "hooks": {
    "PreImagePaste": [
      {
        "matcher": "*",
        "hooks": [
          {
            "type": "command",
            "command": "my-image-handler.sh"
          }
        ]
      }
    ]
  }
}
  • Architectural Alignment: Fits the existing hook architecture (PreToolUse / PostToolUse pattern).
  • Interception & Blocking: Hook receives image metadata and can block auto-processing via a block decision.
  • Maximum Flexibility: Lets users route, log, or transform images before Claude sees them.

Recommended: Option A as a quick win; Option B or C for a full vision pipeline.

Priority

Medium - Would be very helpful

Feature Category

Configuration and settings

Use Case Example

Use Case Example

A developer working across multiple projects pastes UI screenshots, terminal error outputs, and design mockups throughout their day. Instead of Claude describing each image conversationally, they want every pasted image routed through a local Gemma 3 4B vision model that extracts structured data, such as:

  • Error messages
  • UI component names
  • Text content

This data is returned in a consistent JSON format and feeds directly into their next action—whether that is filing a bug, updating a component, or summarizing a design review.

The Key Need: The user, not Claude, decides what gets extracted and how it is structured.

Additional Context

Use Case Example

Scenario: A developer pastes a screenshot of a UI bug during a debugging session.

Step-by-Step Breakdown

  • The Action: The developer spots a visual bug in their app, takes a screenshot, and pastes it into Claude Code using Cmd+V.
  • Today (Unwanted): Claude immediately describes the image ("I can see a modal with misaligned buttons and a truncated label..."). This output is unstructured, conversational, and not actionable. If the developer then tries to run /image-processing, Claude has already interpreted the image, creating conflicting context.
  • With This Feature: The image simply attaches as [Image #1] with no auto-processing.
  • Custom Execution: The developer runs:

``bash
/image-processing [Image #1] --prompt "Extract all visible UI issues as a structured list with component names and suggested fixes"
``

  • Structured Local Output: The local Gemma 3 4B model returns exactly what was requested:

``json
{
"issues": [
{
"component": "ModalFooter",
"problem": "button alignment broken",
"fix": "add justify-content: flex-end"
},
{
"component": "ToastLabel",
"problem": "text truncated at 24px",
"fix": "increase max-width or reduce font-size"
}
]
}
``

  • Downstream Action: The developer uses this structured output directly to create a code fix, write a Jira ticket, or pass the JSON to another automated tool.

The Difference: Claude's default behavior makes the AI decide what is important. The desired workflow puts the developer in control, driving exactly what data gets extracted and in what format.

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗