# Yes Dev > Windows tray app that auto-approves Chrome's Allow remote debugging? prompt so parallel automation clients never block - **Type:** MCP server - **Install:** `agentstack add mcp-dev-newb-yes-dev` - **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior - **Seller:** [dev-newb](https://agentstack.voostack.com/s/dev-newb) - **Installs:** 0 - **Category:** [Integrations](https://agentstack.voostack.com/c/integrations) - **Latest version:** 0.1.0 - **License:** MIT - **Upstream author:** [dev-newb](https://github.com/dev-newb) - **Source:** https://github.com/dev-newb/yes-dev ## Install ```sh agentstack add mcp-dev-newb-yes-dev ``` Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent. ## About 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](https://github.com/dev-newb/yes-dev/releases/tag/v1.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](https://github.com/ChromeDevTools/chrome-devtools-mcp/issues/825), was **closed as not planned** in March 2026 - so a built-in "always allow" is not coming. [#1794](https://github.com/ChromeDevTools/chrome-devtools-mcp/issues/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+. ```bash pip install pystray pillow ``` ```bash 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. ```bash pip install rumps pillow pyobjc-framework-Cocoa pyobjc-framework-ApplicationServices ``` ```bash 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. ## Pricing - **Free** — Free ## Security capabilities Automated source analysis of v0.1.0 — what this tool can access: - **Network access:** yes - **Filesystem access:** no - **Shell / process execution:** no - **Environment & secrets:** no - **Dynamic code execution:** no *"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.* ## Versions - **0.1.0** — security scan: passed — Imported from the upstream source. ## Links - Listing page: https://agentstack.voostack.com/l/mcp-dev-newb-yes-dev - Seller: https://agentstack.voostack.com/s/dev-newb - Browse the marketplace: https://agentstack.voostack.com/browse --- Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.