[BUG] macOS desktop 2.9939.2: computer:// links to files/folders in a connected folder render as plain text (or get disabled after ~1s) — Finder can no longer be opened from the transcript
Status Open
Maintainer reply None cached
Activity 3 comments · opened Sep 25, 2026
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?
Environment
- macOS, iMac (Apple Silicon)
- Claude desktop app 2.9939.2 (2026-09-24). Worked fine up to and including 2026-09-24 before the update.
- Cowork session with a connected project folder (Dropbox). Also reproduced in a cloud session linked to the same Mac, and in a session with no connected folder.
What worked before
Claude writes files directly into my connected project folder and returns a list where each file name is a computer:// link to the file, plus a computer:// link to its folder ("Show folder"). Clicking the folder link opened Finder in that directory. That is how I deploy: I pick the files in Finder and drag them to my FTP client, in the order I choose.
What happens now
computer://links in the assistant message are rendered as plain text, or appear as links for about one second and are then disabled.- File cards (SendUserFile) only offer "Download". "Show in Finder" reveals the copy in ~/Downloads, not the file in the project folder.
- The same
computer://links inside a published artifact open a blank page. - Right-click → "Open in → Finder" on a file link does nothing (see #65628).
What Should Happen?
Expected
computer:// links to paths inside a connected folder stay clickable and open Finder (reveal file / open directory), as before 2.9939.2.
Error Messages/Logs
Steps to Reproduce
- Start a Cowork session with a connected folder.
- Ask Claude to edit a file in that folder and to reply with a
computer://link to the file and to its folder. - Click the links.
Claude Model
None
Is this a regression?
Yes, this worked in a previous version
Last Working Version
_No response_
Claude Code Version
Claude 2.9939.2 (d3e504)
Platform
Anthropic API
Operating System
macOS
Terminal/Shell
Terminal.app (macOS)
Additional Information
_No response_
3 Comments
Possibly related, same family of regressions in recent desktop builds:
Still reproducible on 2.9939.2 as of 2026-09-26.
Same issue here, still present in 2.9939.4.
computer:// links to files and folders render correctly while Claude is typing, but disappear as soon as the response finishes. Nothing is left to click, so opening files in Finder from the conversation no longer works at all.
This worked fine before the 2.9939.x update. Opening deliverables directly from the chat was a core part of my daily workflow, so a fix would be much appreciated.
Same regression here, independently observed and reported through the in-app support messenger on 27 September 2026.
Environment: Claude desktop for macOS 2.9939.2 at the time (now 2.16120.0, still reproducible). Cowork, cloud sessions linked to this Mac. Connected folders are Google Drive for Desktop shared drives, so paths sit under ~/Library/CloudStorage/GoogleDrive-…/.
Last known working: 24 September 2026. First seen broken: 27 September 2026.
Defect 1, computer:// links. A markdown link whose target is a computer:// URL with the percent-encoded absolute path of a file in a connected folder used to render as a file card that revealed or opened the file in place. It now renders as plain blue inline text, and clicking it opens the artefact pane inside the app rather than touching the file. This has applied retroactively: links in older conversations that rendered as working cards at the time now render as plain links too, with the message content unchanged. That points at the renderer rather than the model output.
Defect 2, sent file cards. A file card for a file that exists in a connected folder offers Download as its primary action. The chevron offers only Open in Microsoft Word, Show in Finder and Open in Google Drive. Show in Finder reveals a copy in ~/Downloads, not the source file, and every click creates another numbered duplicate (_1, _2, …). The user's default application for the file type is not offered.
Impact. The workflow depends on there being exactly one copy of each file, in a known folder, which is the one that gets edited. Both defects route the user to a Downloads copy instead, so edits are silently made to the wrong file. The only remaining route to the real file is copying the folder path out of a code block and pasting it into Finder's Go to Folder.
On the suspected cause. If this came from the proposed fix in #94707 (render out-of-scope file links as plain text), it has over-reached: these files are inside folders explicitly connected to the session, not outside the working directory.