Yes Dev

A tray app that clicks Chrome's "Allow remote debugging?" prompt for you. Windows and macOS.

Chrome 144+ asks for consent every single time a client attaches to the remote debugging endpoint. If you drive Chrome with more than one agent or automation client, those prompts stack up and each one blocks its client until a human clicks Allow. Yes, Dev sits in the tray and answers them.

Measured on Chrome 151: four parallel attaches went from ~35 seconds of waiting on a human to 2.4-4.4 seconds, unattended.

Each approval releases one cloud, which drifts away from the tray and fades. Shown here against a plain backdrop; on a real desktop they drift over whatever is behind them.

Field data, from the machine it was built on: 454 approvals over 8 days, one failed click (99.8% success), no runaway pauses, and it came back by itself after a reboot. That figure is from the Windows build, which has the mileage; the macOS build is newer and is described honestly under [Known limitations](#known-limitations).

> ### Windows: update if you are running 1.0.0 > > The 1.0.0 engine leaked memory, and badly. It walked the UI Automation tree > four times a second whether or not a prompt was there, and those elements hold > native memory that puts no pressure on the managed heap - so .NET never > collected, and nothing was ever released. Measured at ~9 MB/min, about 13 GB a > day. It was found in the field at 51.5 GB private after ten days, with > Windows compressing 11.8 GB to cope. > > The same build also let the engine outlive its tray. The burst guard and the > disarm timer both live in the tray, so an orphaned engine keeps approving > prompts with nothing watching the rate - the 51.5 GB one had been running > unattended for five days. > > Both are fixed in 1.1.0. > If you are on 1.0.0, git pull and restart the tray. Full detail, with the > before and after measurements, is in the [changelog](CHANGELOG.md).

Why not just turn the prompt off?

You can't, and this is not a gap waiting to be filled. There's no flag, no policy, no "remember my choice". The RemoteDebuggingAllowed enterprise policy only enables or disables the feature outright.

The request to persist approval, #825, was closed as not planned in March 2026 - so a built-in "always allow" is not coming. #1794, about the prompts stacking up when several clients connect at once, is still open. Clicking the button is the only route, which is what this does.

Read this before you install it

That prompt exists to stop a malicious local program from seizing your signed-in browser: full access to your cookies, your saved data, and the ability to navigate anywhere as you. Auto-approving means any local process that attaches gets in, not just the ones you started.

On a single-user dev machine that's usually a fine trade. It is still a real reduction in protection, so Yes, Dev ships with two mitigations on by default:

• Stay on for a fixed window (15 min / 1 hour / 4 hours), then it disarms itself.
• Burst guard reacts if approvals spike past 60 in a minute, which is well

clear of normal load but far below a runaway loop. By default it asks what to do, with a visible five-second countdown: Stop or Allow for one hour. Letting the timer run out stops it, because that is the safe answer to a burst you were not expecting. Set it to Stop silently instead and it pauses without asking, re-arming a minute later. Turn the guard off entirely if your workload makes it noise.

The 60/min default is measured, not guessed: several agents working in parallel peaked at 15 approvals in the busiest minute of a real session. Set your own limit from the tray if your workload is heavier.

Both mitigations live in the tray, not in the engine, so the tray dying must not leave an engine approving prompts with nothing watching the rate. On macOS the engine is passed --exit-with-parent and stops itself the moment it is reparented; on both platforms the tray kills the engine on the way out.

If you only need automation against a throwaway profile, you don't need this at all: launch Chrome with its own --user-data-dir and it never prompts. This tool is for when you need your real, signed-in browser.

Install

Clone the repo, then follow your platform. requirements.txt covers both - its markers install only what your platform needs, so pip install -r requirements.txt works either place.

Windows

Requires Windows and Python 3.9+.

pip install pystray pillow

pythonw yes_dev.pyw

Right-click the tray icon and tick Start at login to make it permanent (it drops a shortcut in your Startup folder - no scheduled task, no admin rights).

macOS

Requires Python 3.9+. Use a python.org build, or a Homebrew one with Tk, since the burst dialog is Tk. Built and verified on macOS 26 with Chrome 152; nothing here is new API, but no older macOS has been tested.

pip install rumps pillow pyobjc-framework-Cocoa pyobjc-framework-ApplicationServices

python3 yes_dev_mac.py

Then grant Accessibility, which macOS requires before any process may drive another app's UI. The menu's top section shows whether you have it; clicking Accessibility: NOT granted raises the system prompt and opens System Settings > Privacy & Security > Accessibility. Without it every attribute read comes back empty and the app looks broken rather than unpermitted.

Run as a loose script, that grant attaches to your Python binary - fragile, because it breaks when the interpreter path changes, and far too broad, because everything that interpreter ever runs inherits it. A signed .app bundle is the right home for it and is not built yet; see [Known limitations](#known-limitations).

Getting Chrome to prompt at all

From Chrome 136, --remote-debugging-port is ignored on your default profile unless it is paired with a non-default --user-data-dir - and a throwaway profile never prompts, so it is not the thing to test against. To attach to your real, signed-in browser, turn on Remote Debugging at chrome://inspect/#remote-debugging. Each attach to the browser endpoint then raises the consent prompt, which is what this app answers. The consent gates the CDP WebSocket handshake itself, so a blocked client sits waiting mid-handshake.

The menu

| Item | What it does | |---|---| | On | Master switch. Off means the engine isn't running at all. | | Accessibility (macOS) | Whether the permission is granted; click to request it and open the settings pane. | | Start at login | Windows: a Startup folder shortcut. macOS: a LaunchAgent. | | Stay on for | Auto-disarm after 15 min / 1 hour / 4 hours, or stay on until you say otherwise. | | Speed | Poll interval: 150ms / 250ms / 750ms. | | Approve notice | How approvals are announced: floating puffs (default), a toast card, or silent. | | Pause on burst | Trip past 30 / 60 / 120 approvals a minute, or off. Then either ask me first (5s dialog: Stop, or Allow for one hour) or stop silently and re-arm after a minute. | | Observe only | Log the dialogs but don't click - useful for a first look. | | Include Microsoft Edge | Watch Edge windows too. | | Open log / Open config | The data directory for your platform (see [Files](#files)). |

The icon is green when armed, amber when observing, grey when off, red when paused, and carries a running approval count - in the tooltip on Windows, in the menu on macOS.

How it works

Three processes on both platforms, and the seams between them are plain text, which is why a second platform could be dropped in without touching the shared logic:

tray            owns config, the menu, the counter and the burst guard
  |
  +-- engine    finds and clicks the dialog
  |             appends "[ACTION]" lines to yes-dev.log   - Google Chrome"
  Pane    BrowserRootView
    Pane    Chrome_WidgetWin_1  "Allow remote debugging?"     BubbleFrameView > DialogClientView > ButtonRowContainer
        Button  MdTextButton   "Allow" | "Cancel" | "Turn off in settings"

watcher.ps1 walks exactly two levels down from each browser frame, matches the host window by title, and invokes the Allow button via UI Automation's InvokePattern. That means no mouse movement and no focus stealing - it works on background windows while you keep typing somewhere else.

Finding the dialog on macOS

Same shape of problem, different tree. Here the dialog is attached to the browser window, as an AXSheet, wrapping an alert whose subrole is the thing worth matching on:

AXApplication  "Chrome"
  AXWindow  " - Google Chrome"
    AXSheet  "Allow remote debugging?"                     Toast card`
  writes to `tray.log` instead. Floating puffs, the default, are unaffected.
- **Autostart works but is untested across a real logout.** The LaunchAgent is
  written and loaded correctly; surviving an actual logout and login has not
  been proven the way it was on Windows.
- **Less mileage.** The Windows build has 454 real approvals behind it. The
  macOS build has been verified end to end against live prompts - engine, tray,
  overlay, teardown - but it has not yet run for days on end.

## License

MIT

## Source & license

This open-source MCP server is cataloged on AgentStack and links to its original source — we do not rehost the code.

- **Author:** [dev-newb](https://github.com/dev-newb)
- **Source:** [dev-newb/yes-dev](https://github.com/dev-newb/yes-dev)
- **License:** MIT

Install and usage instructions live in the source repository linked above.