Can Claude Code See My Screen? The Honest Answer

For anyone typing "can Claude Code see my screen" into a search bar, the honest answer is no — not on its own. Claude Code is a terminal program that reads the files in your project, the output of the commands it runs, and the text inside its own session, but it has no window into your desktop, your browser, or the app you are actually looking at.

Most answers stop at that "no" and move on. The useful half is the and: you can give Claude Code screen context, and how you do it decides whether the agent fixes the right thing or guesses.

Can Claude Code see my screen without any setup?

No. When you run claude in a terminal, it operates on a working directory. Its world is the repository, the shell it spawns, and whatever you type or paste.

It does not watch your monitor. It cannot read the Figma tab behind your editor, the Electron app you are debugging, or the button you are hovering over.

That is why there is no screen recording permission prompt when you install it. macOS only asks for Screen Recording access when a program calls the screen-capture APIs. The Claude Code CLI never does, so the permission never comes up.

What can Claude Code actually see, then?

It sees text that enters the session. That is the whole rule, and every workaround follows from it.

Concretely, Claude Code can read:

• The files in your project, opened with its own tools.
• The stdout and stderr of commands it runs — test failures, stack traces, build logs.
• Anything you type or paste into the prompt.
• Images you attach or paste, which the underlying model reads directly.

That last one is the loophole people reach for first. Paste a screenshot and the model can look at the pixels. So in a narrow sense, screen access means only the frames you hand it, one at a time, by hand.

Is pasting a screenshot the same as giving it screen access?

Not once you are past a one-off. A pasted screenshot is a flat image. The model sees shapes and text, then has to guess which real element you meant.

You circle a toggle in the corner and say "this is broken." The image shows a toggle, a label two pixels away, an icon, and a tooltip. The agent picks one. Sometimes it picks wrong and hands you a confident patch to the element next to the one you meant — a failure I dug into in why Claude Code fixes the wrong element.

Screenshots are also expensive. A full-resolution capture is a large block of image tokens, and it carries no structure — no element names, no roles, no frames. I broke the cost down in why screenshots waste Claude Code tokens.

How do I give Claude Code real screen context?

Give it something readable that is not a raw pixel guess. The most reliable form is a resolved UI element — the actual accessibility node under your pointer, named and typed, delivered as text.

macOS already exposes this. Every on-screen control has an accessibility (AX) entry with a role, a title, a value, a frame, and a parent chain. Ask the system for the element at a screen point and it answers with AXButton, title "Publish", inside AXWindow "Editor". That is a named thing, not a description of one. I walk through the mechanism in how AI agents know which UI element you mean.

The delivery path matters too. You want the context to reach the agent without leaving your machine, which means a local server the agent already trusts — covered in running a local MCP server for agent screen context.

This is the job PinVari does. You hold ⌥⌘A, circle or point at any on-screen element, and speak. PinVari screenshots the region, transcribes your voice on-device, and resolves the exact named AX element you circled — role, label, and frame — then hands that to Claude Code over a local MCP server at 127.0.0.1.

How does Claude Code receive a pointed-at element over MCP?

Through a tool, not a photo. You add the server once with claude mcp add pinvari, and the agent gains a tool called pinvari_next_instruction.

When you point and speak, that tool returns the resolved element path, your spoken instruction, the region you circled, and a screenshot cropped to just that region. The agent reads a named target and acts, then calls pinvari_mark_done to close the card.

Two details make this trustworthy rather than a fancier guess:

• Provenance — each element is tagged circled (you deliberately drew around it, so trust it) or dwelled (the pointer merely passed over it). The agent weights them differently.
• Confidence — every resolution carries a score. Below 0.8 the agent asks instead of silently guessing, the honest default when the AX tree is thin.

There is also a pointer trail. As you talk, PinVari records which control the pointer was on at the instant you said each deictic word, so "move this into that" binds "this" and "that" to the real elements you were pointing at, not to whatever the model infers from word order.

Can Claude Code see my browser or an Electron app?

Not directly, but the resolved-element path handles both, and it reads each surface differently instead of flattening every app into the same pixels.

For a browser, PinVari reads the real page URL from the AX AXWebArea, so the agent knows which route the bug is on. For Electron and Chromium apps, whose accessibility tree is built lazily and often starts empty, it sets AXManualAccessibility and retries until a labeled element appears.

When a surface is genuinely AX-blind — a <canvas>, a game, some custom renderers — it falls back to on-device Vision OCR to read the text. The system degrades honestly instead of pretending it resolved something it did not.

Screenshot, pointed element, or computer use — which screen context wins?

Here is how the common ways of getting on-screen context into Claude Code compare.

Computer-use tools deserve a fair word: they genuinely see and drive the screen, which is powerful for automation. But they take control of your machine and stream frames to a model, and for the everyday job of "here is the thing I mean, go fix it" that is a heavy, less private tool than pointing at a named element.

Is anything uploaded when you give Claude Code screen context?

With PinVari, nothing is uploaded by default. Transcription and OCR run on-device with Apple frameworks, there are no API keys, and the resolved capture travels over a local MCP server to your own agent — Claude Code, Cursor, Codex, or Zed.

You bring your own agent and your own model. PinVari is the layer that turns "the thing I'm pointing at" into a named, executable instruction; it never sits in the middle with your data.

That is also why PinVari ships as a notarized Developer-ID DMG rather than through the Mac App Store. The App Store sandbox forbids the global hotkey and reading other apps' accessibility elements, the two things the whole approach depends on.

FAQ

Can Claude Code see my screen without permission?

No. Claude Code never captures your display, so there is no screen recording permission to grant or deny. It only reads text and images that enter its session — files, command output, and anything you paste or attach.

Does Claude Code need screen recording permission?

The Claude Code CLI does not, because it never calls the screen-capture APIs. A separate tool that captures pixels or resolves on-screen elements may request Accessibility or Screen Recording access, but that is the tool's permission, not the agent's.

How do I let Claude Code see what I'm looking at?

Feed it something readable. The quick way is pasting a screenshot; the reliable way is a local tool that resolves the named UI element you point at and delivers it over MCP, so the agent acts on an identity instead of guessing from pixels.

Can Claude Code take a screenshot itself?

Not of your desktop. It can run shell commands, so it could invoke a screenshot utility, but it has no built-in eye on your monitor and cannot choose what to look at. Anything visual has to be captured and handed in deliberately.

Is pasting screenshots into Claude Code safe?

The image goes to the model that powers your session, the same as any prompt content. It is fine for one-offs, but for repeated UI feedback a pointed element keeps the payload small and, with an on-device resolver, keeps your screen contents from being uploaded at all.

What is the difference between Claude Code and computer use for screen access?

Claude Code reads text and pasted images and does not touch your display. Computer-use agents actively capture live frames and drive your mouse and keyboard, which is stronger for automation but heavier and less private for simply pointing at the element you want changed.