Launching today
Claude Overlay
A floating Claude Code chat that sees your screen
84 followers
A floating Claude Code chat that sees your screen
84 followers
Claude Overlay is a frameless, always-on-top chat window for Claude Code that floats over everything you do. Summon it with a hotkey, ask about whatever's on screen, and Claude captures and reads your monitors before answering. It runs the full Claude Code agent on your own subscription - no API key - so it can edit files and run commands, not just chat. Open source (MIT), Windows.
the auto-shot + real agent combo raises a different question than the privacy-masking one - since it's not just reading the screen but can actually run commands and edit files, what stops a prompt injection sitting on screen (hidden text in a webpage, a doc, an email) from getting treated as an instruction the moment auto-shot captures it? not asking about intentional misuse, more about the screenshot itself becoming an untrusted input to an agent that has real write access
@galdayan This is the sharpest question in the thread, and you've framed it exactly right — it's a harder problem than masking, because the screenshot is genuinely untrusted input flowing into an agent that can act. I won't pretend it's fully solved (it isn't, for any screen-reading agent with write access), but here's the honest posture:
The main line of defense is that the overlay doesn't add its own instruction parser — the screenshot is attached as an observation and the agent underneath is just Claude Code, which is trained to treat tool-observed content (web pages, docs, screenshots) as data to reason about, not as instructions to obey. So hidden "ignore your instructions and rm -rf" text in a page is treated as content it's looking at, not a command — that injection resistance is inherited wholesale from Claude Code, not something I hand-rolled.
Two things that are true and worth being upfront about: (1) it's a no-prompt GUI, so tool calls are auto-approved rather than gated per action — but every command and file edit streams into the chat as a visible chip as it happens, so it's observable, not silent; and (2) you control the exposure — Auto-shot off means nothing is captured unless you opt in, so you're not continuously feeding untrusted screens to it.
Where I want to take it: a proper read-only mode (write tools disabled) so you can point it at an untrusted surface like a browser or inbox with zero write access — which lines up with what another commenter asked re: per-overlay permissions. That combo (read-only + on-demand capture) is the right answer for untrusted screens, and it's high on the roadmap. Really appreciate you raising this one
Hey this could actually save so much time/tokens. However regarding privacy - can you mask out specific regions of the screen (like .env files or sensitive API keys) so the overlay completely ignores them while capturing the rest of your layout? Any considerations around that?
@uddipta Great question — probably the most important one for a tool like this. Short answer: there's no per-region masking. I did consider it, but reliably working out "this rectangle is a secret, ignore it" would add a real chunk of logic — and latency — to every single capture, so I deliberately left it out rather than slow the common path down.
What you do get is control over when it looks: there's an "Auto-shot" toggle — flip it off and the overlay stops screenshotting on its own, so capture becomes manual/opt-in and it only ever sees your screen when you explicitly attach it. A couple more things that help: the screenshots go straight to Claude through your own CLI login (your existing subscription — no API key, no third-party server in between), and the overlay excludes its own window from every capture so it never grabs itself.
So the honest privacy model is "you decide when it looks" rather than "it auto-hides secrets." Thanks for pushing on this 🙏
@shengyanlin Thanks for being transparent about it! One temporary workaround could be that claude warns us if we are about to view sensitive info
@uddipta Love this — honestly a smarter framing than mine, because it flips the cost. Pre-masking means parsing every capture up front (that's the latency hit I mentioned), but since Claude is already reading the screenshot anyway, having it flag "heads up — I can see what looks like an API key / .env here" is basically free: the model that's looking is the one that warns you.
One honest caveat: that warning would be after the fact — by then the shot's already been captured and sent — so it's more "you may want to rotate that / be careful next time" than a hard block. But paired with Auto-shot off (you choose when it looks), it's a nice layered approach.
And the fun part: because it's the real Claude agent driven by a system prompt, this is genuinely prototype-able without a code change — you can just tell it to watch for secrets. Might wire it in as a proper opt-in. Really appreciate you thinking this through with me 🙏
Hi Jason! Let's say I'm using this floating Claude Overlay on a web browser which has a very long content - meaning that we have to scroll down to read the full page. In this case, how can we make Claude Overlay read the whole context in our page?
@ccg_cl Great question, and you've spotted a real limit: a screenshot only captures what's actually on screen (the current viewport), so anything below the fold that you'd have to scroll to isn't in the image.
The nice part is the overlay isn't just "vision" — under the hood it's the full Claude Code agent, so it can go fetch the full content directly instead of relying on the picture:
• Web pages: just paste the URL and ask — Claude pulls the whole page with its WebFetch tool and reads it top to bottom, no scrolling needed.
• Office files (Excel, PowerPoint, Word): because it can actually run commands, you can point it at the file and it'll open it directly via COM automation and read the entire document — every sheet, every slide, every row — not just the slice that's on screen.
• Anything else without a URL (a desktop app, a PDF in a viewer): scroll and fire off a couple of messages — with Auto-shot on, each one grabs a fresh frame — or select-all → copy → paste the text straight into the overlay with Ctrl+V.
So the screenshot is really for "what's on my screen right now"; for long or structured docs it's better to let the agent read the source directly. Thanks for the thoughtful one
@shengyanlin Do you have any plans for updating that feature? So that it can be fully automated.
Congrats on the launch! Since it reads whatever's on screen before answering, how do you handle sensitive info that might be visible (API keys, customer data, etc.) - is there any redaction or is it on the user to be careful what's showing?
@medal411 Thanks! Honest answer: there's no automatic redaction — so yes, it's on you to be aware of what's on screen when you capture. I did look at detecting-and-blurring secrets, but reliably deciding "this rectangle is sensitive" would add real logic and latency to every capture, so I deliberately left it out rather than slow the common path down.
What makes that manageable in practice: (1) capture is opt-in and on-demand — there's an "Auto-shot" toggle, flip it off and it only ever sees your screen when you explicitly attach it, and even with it on it grabs the frame at the moment you hit send, not continuously; (2) the screenshots go straight to Claude through your own CLI login — your existing subscription, no API key, no third-party server in between; and (3) the overlay leaves its own window out of the capture, so it never grabs itself.
So the model is "you decide when it looks" rather than "it auto-hides secrets." One nice follow-up another commenter raised is having Claude flag if it spots something that looks like a key/secret in a shot — an opt-in I'm considering. Thanks for keeping the privacy pressure on
One thing I'd love to see is cross-monitor support for the screenshot capture, specifically the ability to pick which screen Claude reads instead of grabbing everything at once. Would make it way more useful when working across a laptop and external display setup.
@apiliogull53162 Yeah, this is a good one — and it's squarely on my list. Right now it grabs every monitor and hands Claude one labelled image per screen (primary vs. secondary), with no way to say "just this one." On a laptop + external-display setup that's exactly where it gets clumsy — you end up spending tokens (and Claude's attention) on the screen you don't actually care about.
Good news: this one's very buildable. Under the hood it already enumerates each monitor and captures + tags them separately, so adding a "which screen(s)?" picker is a natural next step rather than a rewrite — probably a little per-display toggle. It's open source (MIT) if you'd ever want to take a swing at it; otherwise it's going on the roadmap.
Quick workaround in the meantime: since each screen is labelled in the prompt, you can just tell Claude "only look at my external display" and it'll focus there. Thanks for the great suggestion 🙏
I really like that this is more than just a screen-aware chat. The fact that Claude can act on the file that’s already open makes it feel like part of the workflow rather than another window to manage.
Are you considering making context and permissions configurable for each overlay? For example, one overlay could be tied to a specific project in read-only mode, while another could be allowed to edit files. That could make using multiple overlays feel much safer and more predictable.
Nice work, Jason!
@yuri_liubymov Thank you — "part of the workflow rather than another window to manage" is exactly the feeling I was going for, so it's really good to hear it lands that way.
And yes, this is a direction I find genuinely exciting. Some of the pieces are already there: you can run multiple overlays side by side today — but right now they share one global config, so they aren't independently scoped yet. What you're describing — pin overlay A to project X in read-only, let overlay B edit — is very much the right model, and the building blocks exist under the hood (Claude Code already has permission modes and working-directory scoping; it's mostly a matter of surfacing them per instance). Making each overlay its own little sandboxed context is high on my list. It's MIT if you'd ever want to help shape it — otherwise it's going on the roadmap. Great suggestion