The short version
- OpenClaw, first launched as Clawdbot, became one of the most talked-about AI tools of early 2026 because it could act on its owner's computer. Security firms then found insecure defaults, credentials in plain text and hundreds of malicious add-ons.
- Luminair's Desktop Control lets a Claude session take screenshots and use the mouse and keyboard on your Mac, through a small native helper.
- It is off by default and off again at every launch. Every tool checks the switch before it touches the screen, and again just before each action lands.
- The helper asks macOS for Accessibility under its own signed identity, input is paced and capped per minute, and the menu bar says Clicking… or Typing… whenever the agent is driving.
Everyone wanted one. Then the audits came.
CNBC's profile tells the arc in its headline: “From Clawdbot to Moltbot to OpenClaw.” The agent “was first launched in November by Austrian software developer Peter Steinberger”, went through two name changes, and, by CNBC's count, had “collected over 145,000 GitHub stars”. Fans called it “AI with hands”. People used it to manage email and calendars, browse the web and shop, often by texting it through WhatsApp, Telegram or Discord.
The appeal is obvious. A chatbot tells you what to do. An agent with hands does it. Palo Alto Networks put the cost of that just as plainly: to work as designed, “it needs access to your root files, to authentication credentials, both passwords and API secrets, your browser history and cookies, and all files and folders on your system.” It “can take screenshots and analyze and control your desktop applications.”
The researchers who looked closely found problems in how that power was wrapped. Kaspersky's review lists several:
Open by default
“Authentication is disabled by default, so the gateway is accessible from the internet.”
Keys in plain text
Configuration, memory and chat logs “store API keys, passwords, and other credentials for LLMs and integration services in plain text.”
Poisoned add-ons
Anyone could upload a skill, and “the number of malicious skills reached the hundreds”, some bundling a macOS infostealer.
Palo Alto's summary framed it with Simon Willison's “lethal trifecta”, access to private data, exposure to untrusted content and the ability to communicate out, plus persistent memory, which it called “like adding gasoline to the lethal trifecta fire.”
None of this is a reason not to build agents that act. It is a list of what to design against: access that is always on, controls that are off by default, and actions nobody can see.
A screenshot, one step, another screenshot.
Desktop Control landed in Luminair in August 2026, in five batches. It gives a Claude session two new senses on your Mac.
Eyes. A screenshot tool returns a picture of the main display. The picture is taken by Luminair itself, not by a separate command-line program, because macOS attributes the Screen Recording permission to whoever captures. A spawned capture tool was asked for permission again on every shot; the app's own capture is granted once.
Hands. Six tools, move, click, drag, type, key and scroll, go to a small native helper called deskctl. It is written in Swift, runs without a window, and turns one JSON line on its input into real mouse and keyboard events through macOS's CoreGraphics event API. The model works in screenshot pixels; the helper divides by the display's scale so a click lands where the model saw the button.
The tools are served by an MCP server that lives inside the app process, not a network service. Its instructions to the model describe the loop: “Take a screenshot, decide the next single action from what you see, do it, screenshot again. Work in small verified steps.”
That loop is the point. Desktop Control is for the jobs that have no API: a settings pane, a desktop app with no command line, a form in a native window. For anything with a proper interface, the agent should use that instead.
A switch that is checked twice.
The first rule is about the default. The comment above the feature in desktop/main.js spells it out: the switch is off by default and not saved. It resets to off on every launch, “so controlling the Mac is always a deliberate, per-session act, never something left silently armed.”
The switch is not just a flag the app looks at when it feels like it. It gates the tools in three places:
- Before a turn. When the switch is off, the tool server is not attached to the session at all.
- Before every call. Each of the seven tools checks the switch first and throws before it touches the screen or starts the helper. The error tells the model the switch is the user's, and not to retry until they confirm it is on.
- Just before the action lands. Pacing, described below, can make an action wait. After that wait the switch is checked again, so flipping it off mid-wait means the queued click never happens.
act(), which every input tool goes through. Steps 1 and 5 are the same switch, read twice.Turning the switch off also kills the helper process on the spot, so nothing is left running that could post an event while the row reads off. And a session that has Include connected tools turned off, or a team policy that blocks connectors, does not get the tools even with the switch on.
One thing to know: prompts you send from your paired phone run on the same Mac, so they can use Desktop Control too while the switch is on. That is on purpose, and it is one more reason the switch resets at launch.
The helper that said “ok” and did nothing.
macOS protects mouse and keyboard control with the Accessibility permission. The first version of Desktop Control got this wrong in an instructive way.
The helper only read whether it was trusted. It never asked, so Luminair never appeared in the Accessibility list unless you added it by hand. Worse, the helper was built unsigned, with no team identity. macOS ties a grant to a code identity, so even after you granted Luminair, the helper could not inherit it. And a helper without the permission still answered ok to every command. The commit that caught it, on 5 August 2026, notes that with the permission missing “a `move` still answers ok:true while the cursor never moves.”
Three fixes followed:
- Turning the switch on now asks macOS for Accessibility, with the app's identity, which is what puts Luminair in the list.
- The helper is signed with the same Developer ID as the app, under a stable identifier,
com.overwatch.deskctl, so it is a real sibling of the app and can ride its grant. - Every input action checks that the helper is really trusted. If it is not, the model gets an explicit message telling it not to believe an “ok” and not to keep retrying, because nothing is reaching the screen, and to ask you to turn Luminair on in Accessibility.
The menu-bar row separates the two ways this can fail. Turn Luminair on in Accessibility means you have not granted it. Blocked by Luminair, not by you means you did, and the fault is on our side. You are never sent to flip a switch you already flipped.
No faster than a person.
A model can emit tool calls much faster than anyone can click. The rate limit was in the design from day one, but the first build declared a minimum gap that nothing read. The fix, also on 5 August, made pacing real:
When the cap would mean a longer wait, the tool does not stall. It tells the model to stop: “You are acting faster than a person could. Stop, take a screenshot, re-read what is actually on screen, and continue in fewer, more deliberate steps.” A model that is clicking that fast is usually clicking blind, so the refusal pushes it back into the look, act, look loop.
Screenshots are not paced. They post no input and nothing outside the Mac can see them.
The row that says what it is doing.
The last rule is the one OpenClaw's critics kept circling back to: you should never have to guess whether the agent is acting. Before the August fix, an armed switch looked the same whether Luminair was idle or moving the mouse. The hook meant to report actions existed, but nothing passed it in.
Now each action lights the Desktop control row in the menu-bar panel before the event is posted, and names it: Moving the mouse…, Clicking…, Dragging…, Typing…, Pressing keys… or Scrolling…, with a pulsing dot. It goes quiet on its own 2.6 seconds after the last action, and at once when you turn the switch off.
Find it in the app
- 1Click the Luminair icon in the macOS menu bar. Under Control, turn on Desktop control.
- 2Allow Screen Recording and Accessibility when macOS asks. The row updates by itself once the grant is real.
- 3Ask a Claude session to do something on screen. Watch the row name each action. Turn the switch off at any point to stop it.
Checked, and not claimed.
What this post does not claim
- That Desktop Control is safe against prompt injection. A model that reads a malicious web page while the switch is on can still be misled. The switch, the pace and the indicator bound the damage; they do not remove the risk.
- That it covers every engine. The tools are attached to Claude sessions. Other engines do not get them.
- That it runs on Windows. The helper is a macOS binary, and on Windows the tools are never offered.
- That OpenClaw still has the issues described. Kaspersky's post notes some were patched; we quote what was reported at the time.
For how Luminair keeps secrets out of the agent's reach, read Keys the agent never sees.
Sources
- CNBC · 2 February 2026From Clawdbot to Moltbot to OpenClaw: Meet the AI agent generating buzz and fear globally
- Kaspersky official blog · 16 February 2026Key OpenClaw risks, Clawdbot, Moltbot
- Palo Alto Networks · 29 January 2026OpenClaw (formerly Moltbot, Clawdbot) May Signal the Next AI Security Crisis
Hands, with a switch
Turn on Desktop control from the menu bar when you want it, and watch every action it takes.