[BUG] Claude Desktop — Code tab: "trust verification could not be completed" on folder select (silent failure, regression fixed by downgrade)

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?

On Linux, selecting a folder in the Code tab of Claude Desktop fails immediately with an error dialog:

Something went wrong — Try sending your message again. If it keeps happening, share feedback so we can investigate. Detail: "Trust verification could not be completed. You can try again." (Localized PT-BR: "A verificação de confiança não pôde ser concluída. Você pode tentar novamente.")

The folder trust-approval step ("Do you trust the files in this folder?") never completes, so no Code session can be started for any folder. Critically, nothing is written to ~/.config/Claude/logs/main.log at the moment the dialog appears — the failure is completely silent.

This seems to b a regression: the app worked normally the previous day and broke after what appears to be an automatic update. Rolling back to a previous version fully restored functionality.

Steps to reproduce

1. Open Claude Desktop → Code tab.
2. Select any folder to work in ("Select folder…" / open folder).
3. Error dialog appears instantly with the message above.
4. Check ~/.config/Claude/logs/main.log — no new line is written when the dialog appears.

What Should Happen?

The trust-approval prompt should complete and the Code session should start normally, remembering the trust decision for that folder.

Error Messages/Logs

> **Something went wrong** — Try sending your message again. If it keeps happening, share feedback so we can investigate.
> Detail: **"Trust verification could not be completed. You can try again."**
> (Localized PT-BR: *"A verificação de confiança não pôde ser concluída. Você pode tentar novamente."*)

Steps to Reproduce

1. Open Claude Desktop → Code tab.
2. Select any folder to work in ("Select folder…" / open folder).
3. Error dialog appears instantly with the message above.
4. Check ~/.config/Claude/logs/main.log — no new line is written when the dialog appears.

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

claude-desktop 1.19367.0-1

Claude Code Version

2.1.207 (Claude Code)

Platform

Anthropic API

Operating System

Other Linux

Terminal/Shell

Xterm

Additional Information

Environment

• OS: Arch Linux, KDE Plasma («Wayland / X11 — preencher»)
• Claude Desktop version (BROKEN): claude-desktop-bin 1.19367.0-3
• Claude Desktop version (WORKING, after downgrade): claude-desktop 1.19367.0-1
• Install method: AUR
• App config dir: ~/.config/Claude

What I've already ruled out

This was diagnosed extensively before concluding it's a regression:

• Full restart + re-login — Full quit (Ctrl+Q) and re-authentication. OAuth is healthy in main.log: token cache loads, CA bundle is written (859 certs), [remote-tools-device] authenticated, bridge connects, and there are no 401/403/TLS/certificate errors. Auth is not the problem.
• Clearing web caches — Removed Cache, Code Cache, GPUCache, Service Worker, DawnCache. No change.
• Full local reset — mv ~/.config/Claude ~/.config/Claude.bak followed by a clean login. No change.
• Network / DNS — claude.ai works normally in a browser. When the error fires, the app issues no DNS query at all (verified against the local resolver), so this is not a network, DNS, or attestation issue.
• Note on storage location: folder-trust state for the Code tab lives in ~/.claude.json / ~/.claude/, which is separate from ~/.config/Claude. Even so, the failure tracks the app version, not local state.

Only fix: downgrading to the previous version restored normal behavior.

Additional notes

• The trust-save/verification handler appears to swallow the exception without logging — no entry in main.log when it fails — which makes this very hard to diagnose from the user side. A specific log line / error surface for trust-approval failures would help a lot.
• Possibly related prior desktop trust issues: #57276, #51834, #61782.