[BUG] Cowork: cloud/remote-execution sessions have no "Open in <app>" for local files — `present_files` falls back to "Download and open" (root cause: "Run new tasks in the cloud")

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

When a Cowork task runs in the cloud (Settings → Cowork → "Run new tasks in the cloud" = ON, which is the default), presenting a local file does not produce the native "Open in <app>" card. Instead the file comes back as "Download and open" (a copy), or as a computer:// link that opens the in-app preview panel — which for non-previewable types like video shows "No preview available." This happens even when the file physically lives inside a connected project folder and the desktop app is open and connected.

The same task run locally (toggle OFF) presents the identical file via mcp__cowork__present_files with a working "Open in <app>" card (e.g. .mp4 → "Open in VLC", .txt → "Open in Notepad"). Confirmed: flipping the toggle off and starting a new task restores "Open in [App]".

Root Cause (confirmed)

The trigger is execution mode (cloud vs. local), not the Chat/Cowork → "Home" tab merge (an earlier, incorrect theory).

• Local (on-computer) sessions expose mcp__cowork__present_files, which renders the native "Open in <app>" card and opens the file in place.
• Cloud (remote-execution) sessions do not expose present_files at all. Their only file-surfacing mechanisms are (a) delivering a cloud copy → "Download and open", and (b) emitting a computer:// link → preview panel (no native open; "No preview available" for video).

Because older working sessions were created before "Run new tasks in the cloud" was enabled, they ran locally and had present_files — which is why the behavior looked like a post-"Home"-merge regression when it was really cloud-vs-local.

Is this a regression?

Partly. The "Open in <app>" capability is intact in local sessions but absent in cloud sessions. Since new tasks now default to cloud, users who previously relied on "Open in <app>" (in older, locally-run sessions) experience it as a regression.

Environment

• OS: Windows
• App: Claude desktop (Cowork), build 1.22209.0 (post Chat/Cowork → "Home" merge; not the cause)
• Failing mode: cloud / remote execution ("Run new tasks in the cloud" = ON)
• Working mode: local / on-computer execution (toggle OFF)
• File location tested: inside a connected project folder (<project>\_temp\), e.g. .mp4 video and other types
• Desktop app open and connected in both cases

Impact

With cloud execution on by default, every presented file requires a download/copy step instead of opening in place — even though the file already physically exists in the user's connected project folder and the desktop app is connected. Non-previewable types (video, etc.) have no in-app open path at all in cloud mode. Current workaround: turn "Run new tasks in the cloud" OFF and run tasks locally (loses cloud benefits — background/closed-laptop runs and scheduled tasks that need local folders).

Requested Fix

Make present_files (or an equivalent "Open in <default app>" capability, plus a "Show in Folder" action) available to cloud/remote-execution Cowork sessions for files that live inside a connected project folder, resolving the open/reveal actions through the connected desktop app — so cloud sessions no longer fall back to "Download and open" / "No preview available" for files that are already local. This avoids duplicate downloads, re-download delay, the inability to locate the original, and the broken edit round-trip described in "What Should Happen".

What Should Happen?

Even in cloud/remote-execution mode, when a presented file lives inside a connected/mounted project folder and the desktop app is connected, the card should offer "Open in <default app>" (and a "Show in Folder" action) and open the file in place via the desktop bridge — not fall back to "Download and open" / "No preview available." Cloud sessions should not lose the "Open in <app>" capability for files that already exist locally.

Why "Download and open" is the wrong behavior for already-local files

The file is already sitting in the user's connected project folder, exactly where it belongs. Forcing a download instead of opening it in place causes concrete problems:

1. Duplicate files. It creates a second copy in a separate Downloads folder even though the original already exists in the correct location — cluttering Downloads and leaving two copies to reconcile.
2. Unnecessary delay. It re-downloads a file that is already on disk locally, adding wait time for no benefit.
3. No "Show in Folder." There is no action to reveal the original file in its actual location, so the user can't quickly locate the source — especially painful in a project with many subfolders.
4. Broken edit round-trip / stale-source risk. If the user edits the downloaded copy, they must remember to manually copy it back to the original folder. This is an extra step and error-prone: forget once, and the source file silently stays stale while the user assumes it was updated — leading to lost work or shipping the wrong version.

In short, "Download and open" treats a local file as if it were remote, defeating the point of a connected project folder. Opening in place (plus "Show in Folder") avoids all four problems.

Error Messages/Logs

Steps to Reproduce

1. Settings → Cowork → set "Run new tasks in the cloud" = ON.
2. Start a new Cowork task in a project with a connected local folder. Have Claude present a file that exists in that folder (e.g. <project>\_temp\clip.mp4).

→ Card shows "Download and open"; clicking a computer:// link opens the preview panel with "No preview available" for video. ❌ No present_files "Open in <app>" card.

1. Settings → Cowork → set "Run new tasks in the cloud" = OFF. Start a new task; present the same file.

→ mcp__cowork__present_files renders the "Open in <app>" card (e.g. "Open in VLC"), opening the file in place. ✅

Only variable that changes the behavior: cloud vs. local execution mode.

Claude Model

Not sure / Multiple models

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

Claude desktop (Cowork), build 1.22209.0

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

_No response_