[FEATURE] Allow Claude's macOS Computer Use to operate one app without taking over the user's workstation

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

Single bounded feature request: add a target-scoped, non-disruptive computer-use mode on macOS so Claude can operate one approved app while the user continues using the rest of the Mac. Today a computer-use turn commandeers three forms of shared global interaction state — the system pointer, keyboard focus and input routing, and the visibility of unrelated apps — making concurrent use impossible. These behaviors may have different internal implementation causes, but they are not three standalone feature requests; they are three acceptance dimensions of one user-facing capability: operating a target app without taking over the workstation. This issue requests that outcome and its minimum safety and usability requirements, not any particular internal mechanism.

I understand Anthropic may implement this through multiple internal changes or linked engineering tasks; this issue is intended to remain the canonical end-to-end tracker for the single user-facing capability.

Current observable behavior

Three observable forms of workstation takeover that prevent the requested operating mode:

1. Shared pointer. Claude moves the system pointer, so the user's movements and the agent's movements alter each other's click targets.
2. Shared keyboard focus and input routing. Claude changes foreground focus, so user keystrokes can reach the app Claude is operating rather than the app the user was typing in.
3. Unrelated apps are hidden. Nearly every application that is not the target is hidden, including apps on displays the agent is not acting on, preventing the user from continuing work elsewhere even when those apps are outside the task.

User impact

The user cannot safely use the Mac while a computer-use turn runs. Any attempt to keep working risks input landing in the wrong application, in either direction, so in practice the only safe option is to stop touching the machine until the turn ends.

This reproduces on a single built-in display. A multi-display setup only amplifies the separate app-hiding impact.

Why this is one feature request

Pointer contention, keyboard/focus contention, and unrelated-app hiding may involve different internal components, but they are not independently requested product features here. They are the observable conditions that must be addressed for one operating mode to exist: Claude operating a target app while the user continues using the rest of the Mac. Anthropic may decompose the implementation into separate internal tasks while this issue remains the end-to-end capability tracker.

They also compound rather than merely coexist. Restoring app visibility alone does not solve input collisions. Separating the pointer alone does not help if the apps the user needs are hidden. Preserving keyboard focus alone does not help if the user's physical pointer movement changes the agent's next click target.

What is not being reported

Restoration works. Hidden apps return when the turn finishes, and the Claude window returns to its prior size and position. This issue concerns what happens during a turn.

Configuration surface

I found no documented setting for input arbitration or per-display scoping in Desktop settings or in the public Claude Code configuration documentation. Settings > General (under Desktop app) documents a Computer use toggle and two configurable settings, Denied apps and Unhide apps when Claude finishes. The toggle is all-or-nothing; "Unhide apps when Claude finishes" governs whether apps return rather than whether they are hidden; Denied apps prevents interaction with an app but does not prevent it being hidden and does not address input routing.

Direct evidence from Anthropic's permission-resolution and tool surfaces

I ran Anthropic's computer-use permission-resolution API for a session in which System Settings was the only app being resolved. The relevant response fields were:

{
  "willHide": [
    { "displayName": "Google Chrome" },
    { "displayName": "ChatGPT" }
  ],
  "screenshotFiltering": "native"
}

Neither Google Chrome nor ChatGPT was part of the System Settings task. The willHide field is therefore direct, machine-readable evidence that the product planned to hide unrelated applications for this session; this was not merely an incidental visual effect observed after computer use began.

The screenshot tool's own documentation for this surface states:

Applications not in the session allowlist are excluded at the compositor level — only granted apps and the desktop are visible.

Together with "screenshotFiltering": "native", this establishes that compositor-level, per-application exclusion from model-visible screenshots already ships and was selected for this session. It supports the narrower conclusion that hiding is not required merely to keep applications outside the session allowlist from appearing in those screenshots.

It does not establish that hiding is wholly redundant or can safely be removed on its own. One plausible separate rationale is hit-test consistency: if Claude still uses globally hit-tested pointer events, a window omitted from the model's filtered screenshot could remain physically above the target and intercept a click. Hiding could therefore be a compensating mechanism that makes the model-visible composition correspond to the real clickable surface, or an additional defense-in-depth measure.

If that is the rationale, it reinforces this issue's framing: target-scoped input and unrelated-app visibility need to be solved together. It is not a claim that hiding can simply be removed without changing the input path or otherwise handling occlusion.

The tool surface also documents a background app mode in which launching an app does not bring it to the front and "the user's focus is preserved." This demonstrates that focus-preserving app launch already exists. It does not show that subsequent clicking, typing, dragging, or full computer-use interaction can already occur without foreground activation.

Surface tested: Claude Desktop on macOS. Anthropic's CLI documentation states: "The CLI and Desktop surfaces share the same computer use engine, with a few differences:" — so the CLI may be affected, but I have only tested Desktop.

Proposed Solution

Expected behavior

When Claude operates an approved target app, the user should be able to continue working in unrelated apps without either actor redirecting the other's input, and without unrelated apps being made unavailable.

The UX benchmark for this already ships on macOS today: Codex. OpenAI documents that its agent operates apps "by seeing, clicking, and typing with its own cursor," and that agents can work on a Mac "without interfering with your own work in other apps." That is the user experience being requested here — an agent that uses the computer alongside the user rather than instead of them. I am asking for parity with that experience, not for a specific implementation of it.

This issue does not prescribe whether Anthropic achieves that through process-addressed events, Accessibility actions, capture filtering, virtualization, app-specific adapters, or another mechanism.

Acceptance criteria

These are acceptance dimensions of one mode, not separate feature requests.

• [ ] Pointer isolation. User movement of the physical pointer does not alter Claude's next action target, and Claude does not move the user's pointer while non-disruptive mode is active.
• [ ] Input isolation. User typing in an unrelated app remains in that app and does not enter the app Claude is operating.
• [ ] Continued usability. Unrelated apps remain visible and usable, while also remaining outside model-visible capture.
• [ ] Target visibility. The UI clearly identifies which app or window Claude is operating.
• [ ] Explicit fallback. Where non-disruptive operation is unsupported, Claude states that before or when falling back to shared foreground control — so an implementation cannot pass by silently falling back in every case.
• [ ] Existing safeguards preserved. App approvals, model-visible capture restrictions, Esc abort behavior, and restoration behavior do not regress.

Non-goals

• No requirement that every macOS application support non-disruptive operation immediately.
• No prescribed macOS API or internal architecture.
• No request in this issue for user-configurable per-display hiding rules.
• No request in this issue for a new action-log product or generalized observability system.
• No request to weaken app approvals or capture isolation.
• No request to change the existing shared-control mode where an application cannot support the new mode.

Possible implementation directions — non-normative

The following are possible directions, not requested APIs or acceptance requirements. Each would need empirical validation per application and macOS version.

• Process-addressed Quartz events (CGEventPostToPid) can post an event to a specified process rather than the general session event stream. Whether this provides reliable pointer-independent clicking, typing, dragging, and shortcut handling varies by application and requires testing. It should be treated as one candidate transport, not a universal solution.
• Accessibility actions (AXUIElementPerformAction with actions such as kAXPressAction) can actuate controls exposed in an application's accessibility tree without pointer movement, and Accessibility is already a required permission for computer use. Coverage depends on the accessibility tree each application exposes; custom-rendered or canvas-like interfaces may provide few or no actionable elements.
• Narrower capture filters. ScreenCaptureKit supports capture filters limited to a specified window, and display filters that include or exclude selected windows or applications. Behavior for occluded, minimized, protected, or unavailable windows would need to be validated for this use case.
• A visible agent pointer, so the user can see what is being driven — along the lines of what Codex ships.
• Per-application capability detection with disclosed fallback, so unsupported apps degrade predictably rather than silently.

Combining narrowly filtered capture with process-addressed or accessibility-based actions could reduce both visual exposure and input contention, but the complete trust boundary would still require separate handling of focus, transient UI, helper processes, notifications, clipboard access, and action verification.

Some genuine platform constraints exist and are worth naming. Physical keyboard input ordinarily follows the active application and focused UI element, and Secure Event Input can interfere with global keyboard observation and may affect some synthetic-input approaches; behavior should be tested by application and macOS version rather than assumed. Some programmatic actions can be addressed directly to an application or accessibility element, but full background keyboard semantics are not universally available. None of that explains hiding applications on displays the agent is not touching, or moving the user's pointer in order to click.

Alternative Solutions

Workarounds tried

• Esc to abort (documented). Esc stops the turn from anywhere and restores apps, and it works as documented. But aborting is not coexisting — it trades the workstation back for the task's progress. It is the right escape hatch for a runaway turn, not a way to work while a normal turn completes.
• "Unhide apps when Claude finishes." Works as documented, but governs whether apps return, not whether they are hidden.
• Denied apps. Prevents interaction with specific apps; does not prevent them being hidden and does not address input routing.
• Avoiding computer use entirely, routing work through MCP connectors, Bash, or Claude in Chrome. This works, but the feature then goes unused for precisely the GUI-only tasks it exists for.

None of these let the user and Claude use the machine at the same time. Today the only ways to resolve a collision are to stop touching the machine, or to stop the turn.

Prior art: this UX exists on macOS today, from a direct competitor

OpenAI's Codex announcement (April 16, 2026) states:

With background computer use, Codex can now use all of the apps on your computer by seeing, clicking, and typing with its own cursor. Multiple agents can work on your Mac in parallel, without interfering with your own work in other apps.

Their Computer Use documentation separately lists as a supported macOS use case:

On macOS, running a scoped task in the background while you keep working elsewhere.

So a separate agent cursor, and background operation while the user keeps working, are explicitly documented product behavior on the same operating system. (One narrower point is my own observation rather than documented: in my use, Codex also does not hide my other applications.)

The contrast with Codex's Windows implementation is instructive, because there their documentation is explicit that Computer Use "runs on the active desktop," that "It can't operate in the background while you keep using the same Windows session," and that users should "expect ChatGPT to move the pointer, type, and take over the foreground while the task runs," recommending you "use a secondary device, a VM, or stop the task before using that desktop yourself."

That Windows description closely matches the observable shared-control behavior I see in Claude Desktop on macOS. OpenAI's documented macOS behavior shows that foreground takeover is not an unavoidable macOS-wide requirement, even though app-specific constraints may still require fallback to shared foreground control.

I want to be direct about why this matters beyond ergonomics: for GUI-only work this is a concrete, repeatable reason to choose a competitor's agent over Claude, on tasks where Claude is otherwise stronger. Reaching UX parity with Codex here is the ask.

Secondary: Claude in Chrome shows the same thing internally, but does not generalize

When Claude drives a page through the Chrome extension, it does not move my physical cursor, does not take my keyboard, and does not hide my applications — I keep working while it runs. So non-disruptive agent control is not foreign to this product.

It is not a substitute, though: it works because the browser exposes an extension surface. Native apps, simulators, design tools and hardware control panels do not, and shipping a Claude extension per application is not a realistic path. For native applications without a dedicated connector, CLI, or app-specific automation surface, Desktop computer use is the remaining general-purpose route — which is why its shared-control behavior matters.

Priority

High - Significant impact on productivity

Feature Category

Other

Use Case Example

Reproduction

1. Open App A (the target) and App B (unrelated).
2. Start a computer-use turn operating App A.
3. Attempt to type into App B and move the pointer while the turn runs.
4. Observe pointer contention: user pointer movement and agent pointer movement alter each other's targets.
5. Observe focus and input redirection: keystrokes intended for App B can reach App A.
6. Observe App B and other unrelated apps being hidden, including on displays the agent is not acting on.
7. Concurrent user work is not possible for the duration of the turn.

Expected: steps 4-6 do not occur. The user keeps working in App B while Claude operates App A, with a clear indication of which app Claude is driving.

This reproduces on a single built-in display. On a multi-display workstation the hiding behavior additionally clears screens that have nothing to do with the task.

Additional Context

Environment

• Claude Desktop 1.30096.5
• macOS 26.6.1 (build 25G76), Apple Silicon (arm64)
• Reproduces on a single display; also observed on a five-display setup
• Tested on Desktop only

Related

• #39625 — [DOCS] Computer use docs missing multi-monitor display-switching guidance
• #69286 — partially overlaps on hiding of non-allowlisted apps (Windows-specific and narrower)
• #82191 — related macOS frontmost-window / hit-test problems, different requested outcome

References

• Desktop application → Let Claude use your computer
• Let Claude use your computer from the CLI
• Codex computer use documentation

On the security tradeoff

This does not ask for the trust boundary to be weakened. The request is to preserve the current documented app-approval and screenshot-isolation policy: content outside the approved target set must not be included in model-visible captures.

One property does change, and it is worth naming rather than glossing over. Today, visible pointer movement and app hiding provide an incidental signal that computer use is active, and can make unexpected actions more noticeable. A non-disruptive mode would reduce that signal, so it needs a replacement: a persistent indication of which app is being driven, with Esc continuing to abort from anywhere. That indication is listed above as an acceptance criterion rather than a nice-to-have, for exactly this reason.