LCU: Codex computer use, detached from the Codex app

The runtime stays in the app, the harness stays yours

LCU takes the computer-use capability that ships inside the official ChatGPT desktop app and hands it to an agent harness of your choosing, without requiring Codex authentication. The desktop app is still required, and the split is worth being precise about: the app supplies the runtime and the instructions, while LCU handles setup and harness integration. LCU does not reimplement computer use, and it does not ship its own model.

What that buys is a decoupled arrangement. An agent running inside Pi, Codex CLI or Claude Code can read windows, click, type and take screenshots on the desktop, while the model side of the loop stays in your harness and your own model account. The repository description calls it Codex computer use, decoupled from the app, for usage inside any harness, and that is accurate: the app is a runtime provider, not the agent.

The implementation is JavaScript, and there is no Python requirement on any platform. LCU runs on the Node that ships inside the app, checks the installed app for compatibility, and uses its original runtime. The repository layout backs this up, with an lcu/ source directory, an adapters/ directory, bin/, scripts/, tests/, a runtime.lock.json, a tested-versions.json and a docs/ tree that the README links into repeatedly.

Two permission systems, and neither one replaces the other

The design decision that makes LCU usable in production is that it does not collapse permissions into a single switch. There are two independent layers, and they sit in different places.

The first layer belongs to your harness. Claude's own don't ask again on the first card, Codex's tool approval and equivalents decide whether the agent is even allowed to call LCU's tools at all. That decision is made by the harness, with the harness's own policy.

The second layer belongs to LCU, and it is per application. LCU decides, for each app, whether that agent may touch it, and it does so in every permission mode. The point is that an agent approved to use the tools still meets a per-app wall for the specific program it wants to drive, which is the boundary that matters when a model is clicking around a real machine.

For unattended machines such as VMs and CI, lcu setup --approval auto pre-allows LCU's two model tools in the harness while leaving per-app approval in force. That is the option to use on a disposable box, and it is deliberately narrower than switching approvals off entirely.

lcu-approve turns a failed prompt into a native question

The first time an agent controls an application such as Zed, Notes or Safari, the computer-use runtime asks you to allow it. Inside the Claude app's Code tab that request used to fail outright with the message Computer Use was not approved, which left the agent stuck rather than the user informed.

lcu setup --agent claude-code now installs a small Claude Code mod called lcu-approve that asks the question the way the rest of the app asks questions. You get a question card in the Claude app, which flags the session as needing input, and a Computer use approval pane in the terminal. The choices are Allow this conversation for the current chat only, Always allow to remember the app, which is only offered when the runtime permits it, and Deny to refuse.

The boundary is enforced by the runtime, not by the mod. Only you can answer, because the model cannot see, press or fake the pane. High-risk applications show the runtime's own warning, reworded to say computer use and the agent, and the app hosting the agent is never approved. The feature needs the Claude app or Claude Code 2.1.287 or later, and the README notes that in the Claude app you register LCU through Claude Code with lcu setup --agent claude-code rather than through Settings, Connectors.

lcu apps puts the always-allow list under your control

Remembering an app is convenient until you want to take the permission back without opening the Codex app. On macOS the terminal can do it directly, and the three commands cover the whole lifecycle:

lcu apps                 # what is always allowed today
lcu apps allow Zed       # Touch ID (or your password), then Zed is allowed
lcu apps revoke Zed      # take it back

Listing is free, and an app name, a bundle identifier or a path to an .app file all work as the argument. Allowing and revoking require you to be at the machine, so an agent that tries to run them is stopped by the prompt. Running sessions pick the change up immediately, which avoids the case where a long-lived session keeps a permission that you just withdrew.

High-risk categories come with a warning, browsers and password managers among them. Some applications the Computer Use runtime refuses outright, Terminal and iTerm2 are the named examples, and those are declined rather than approved. The same Approved apps panel is reachable inside a session with the /computer-use-apps command, showing one line per always-allowed app with a Revoke action, applications that are no longer installed grouped below, the current conversation's grants, and an Allow field.

Cross-turn Computer Use is opt-in and not a security boundary

In Claude Code, Computer Use normally ends when the turn that started it ends. The visible symptom is an error saying Computer Use is unavailable because the current turn ended, which hits background subagents that are still working and turns that reuse an ended turn id.

An opt-in setting keeps computer use available for every turn of the session:

lcu cross-turn           # status
lcu cross-turn on        # Touch ID (or your password) on macOS
lcu cross-turn off       # no prompt

It is off by default, lcu setup --cross-turn on|off sets it too, and interactive setup asks once. The scope is narrow. It affects only the Claude Code relay, so Codex, Pi, Oh My Pi and Hermes ignore it, and per-app approvals on macOS and Windows plus your harness's own tool approvals still apply. With the setting enabled, a foreground subagent finishing no longer ends the parent's computer use.

The project is honest about the limits here. It calls the setting a guard against accidents, not a security boundary, because anything running as your account can edit the file or pass --unattended, which the documentation points at for disposable sandbox machines where nobody can answer the prompt. Read that as the real design constraint: cross-turn is for a sandbox, and the Touch ID prompt is what keeps it honest on a desktop you actually use.

Two install paths, and the platforms left out

The fastest route is to hand two commands to the agent and let it walk you through prerequisites, which is what the quick start asks for: check the OS, architecture and prerequisites, then guide through the required permissions. On Claude Code on an Apple Silicon Mac the plugin manager does the same job:

claude plugin marketplace add amontlabs/lcu
claude plugin install lcu@lcu

Manual installation means downloading an archive and the matching .sha256 file from the latest release, with names of the form lcu-<version>-darwin-arm64.tar.gz for macOS on Apple Silicon, lcu-<version>-linux-arm64.tar.gz for Linux ARM64 and lcu-<version>-linux-x64.tar.gz for Linux x86-64.

The supported set is short. Linux needs an Ubuntu 24.04 compatible glibc system, an active X11 desktop and D-Bus. macOS needs the signed ChatGPT app with Accessibility and screen-recording permissions approved on first use. Windows 11 x64 is described as a candidate deferred from this delivery, and Intel Macs, native Wayland and musl Linux are unsupported. Codex CLI users are told to update before setup to get the required hook support. The site lives at lcu.amontlabs.com, and the licence is MIT.

Adapters, the Chrome path and a fast release line

Desktop control is one half of the feature list. The other half is the browser. Chrome, when enabled, can be read and controlled through the official extension, with site approval as the gate, so browser work goes through a per-site consent rather than through the desktop path.

Harness support is delivered as adapters. Ready adapters exist for Pi, Codex CLI and Claude Code, with experimental Oh My Pi and Hermes integrations, and docs/ADAPTERS.md is the reference for setup and for verification limits. That file also holds the Claude Code and Claude app native approval write-up, while docs/INSTALLATION.md carries the install, uninstall, approval mode, cross-turn and Windows candidate sections, and docs/PARITY-STATUS.md records tested behavior.

The release line moves quickly. Tags v0.11.2, v0.11.3 and v0.11.4 shipped on 2026-10-10, 2026-10-12 and 2026-10-14, and the last push was on 2026-10-19. That cadence is worth weighing against a stability concern: a project releasing several times a week will change the behaviour your harness sees, so pin the version you test with and read tested-versions.json, rather than tracking the latest tag by default.

Editorial conclusion

LCU is the right pick for anyone who wants desktop control from a harness other than Codex, especially on a Mac where Touch ID backed app approvals are the deciding feature, and for teams running unattended machines with lcu setup --approval auto. It is the wrong pick if you cannot install the official ChatGPT desktop app, on Windows 11 x64, which is still only a candidate, or on Intel Macs, native Wayland and musl Linux, which are unsupported. Before adopting, read docs/PARITY-STATUS.md and check tested-versions.json against the app version on the machine, confirm the browser extension path is acceptable for Chrome, and decide explicitly whether lcu cross-turn on is worth the fact that it is a guard against accidents rather than a security boundary.

Frequently asked questions

Official sources

1. amontlabs/lcu on GitHub
2. License: MIT
3. Project website
4. README
5. Releases