[BUG] Linux: "Couldn't link this session to a computer" — claude-native has no enclave-key implementation (`linux-not-yet-supported`), so td-v2 device registration can never succeed

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?

Update: this report originally blamed a poisoned none state in ~/.config/Claude/ant-device-registry.json (suspend/resume + offline window). That was wrong — clearing that state does NOT fix the issue (tested: the warning reappears seconds after app start). The real root cause is below; the original observations are kept in Error Messages/Logs since they remain accurate as symptoms.

On the Claude Desktop Linux beta, every Cowork session shows the warning banner "Couldn't link this session to a computer, so attached folders can't be used" (internally cowork-unbound-folders-banner) and is silently provisioned unbound. This is not a local configuration problem and there is no user-reachable fix.

Root cause, traced through the shipped app bundle:

1. Session-to-computer binding requires resolving the device-registry row-PK, which requires the device's enclave key. The resolution path races the key fetch against a timeout and gives up (app.asar, device-registry module):

const p = await Promise.race([K5e(t), new Promise(g => setTimeout(() => g(void 0), T6))]);
if (p === void 0) {
  _.warn("[device-registry] enclave key unavailable — refusing to resolve row-PK");
  return;
}

1. The key fetch calls into the native module:

async function $bt(e) {
  ...
  const t = wr();                      // @ant/claude-native
  if (t) {
    const r = await t.hardwareKeyGetOrCreate(n);
    ...
  }
  throw new Error("DeviceRegistry: claude-native unavailable");
}

1. The Linux build of the native binding (app.asar.unpacked/node_modules/@ant/claude-native/claude-native-binding.node) does not implement hardware keys at all. The binary contains the hardcoded failure string:

hardwareKeyUnavailable: linux-not-yet-supported

and links no TPM or secret-service library (no tpm2-tss, no libsecret) — the hardware-key API is a stub that always throws. The JS error classifier next to the call site even has a dedicated category for it ("linux-not-yet-supported" → "linux", alongside "PlatformCryptoProvider" → no_tpm and macOS -34018 → entitlement).

1. Consequence: on Linux the enclave key can never exist → device registration can never mint a row-PK → every session↔device bind fails (signCreateSessionBind → not_registered) → sessions silently fall back to unbound → the banner. The underlying probe error is only logged at debug level ([device-registry] own-pubkey probe failed), so main.log never shows why.

Cowork linking worked on this machine from install (Jul 9) until ~Jul 17–19 with no client change (it broke before the 1.18286.2 → 1.22209.3 upgrade), which suggests the td-v2 attestation requirement was enabled server-side around then — turning the long-standing missing Linux implementation into a hard failure.

Everything else is healthy and was ruled out: the local Cowork VM boots and connects cleanly every time (vm_boot completed, guest ready, API reachability: REACHABLE, Startup complete), /dev/kvm + kvm group + qemu/virtiofsd/OVMF fine, gnome-keyring running and unlocked, TPM 2.0 present on the host (/dev/tpm0, /dev/tpmrm0) but unused by the binding.

Not recoverable by: app restart, OS reboot, app upgrade, clearing ~/.config/Claude/ant-device-registry.json (tested), sign-out/sign-in (per #78671).

What Should Happen?

Either implement the enclave key on Linux (TPM2 via /dev/tpmrm0 where available, with a software-backed fallback — the API already carries an isHardwareBacked flag), or have the backend accept session binds from platforms without enclave-key support instead of hard-requiring td-v2 attestation.

Either way, surface the failure: the current behavior (debug-level probe error, silent unbound fallback, generic banner) is undiagnosable for users — the banner even suggests "Update Claude", which cannot help, since no shipped Linux build has the implementation.

Error Messages/Logs

User-facing, on every Cowork session start:
"Couldn't link this session to a computer, so attached folders can't be used"

main.log, repeated on every Cowork session start / remote-tools use:

[device-registry] enclave key unavailable — refusing to resolve row-PK
[remote-file-tools] td-v2 attestation mint unavailable: DeviceRegistry: device not registered (no row-PK for this account)

The warning reappears ~3 s after every app start, e.g.:

2026-07-20 01:02:35 [info] Starting app { appVersion: '1.22209.3', ... }
2026-07-20 01:02:38 [warn] [device-registry] enclave key unavailable — refusing to resolve row-PK

Native binding failure string (strings on claude-native-binding.node):

hardwareKeyUnavailable: linux-not-yet-supported

Persisted keyless state in ~/.config/Claude/ant-device-registry.json
(record of the state, not the cause — removing it changes nothing):

{"<account-uuid>":"none:1784292593359"}

Meanwhile the VM layer works every time:

[VM:start] Beginning startup, bundlePath=/home/…/.config/Claude/vm_bundles/claudevm.bundle
[VM:steps] vm_boot completed (1002ms)
[guestrpc] guest connected … guest ready
[VM] API reachability: REACHABLE
[VM:start] Startup complete, total time: 55878ms

Steps to Reproduce

1. Install the Claude Desktop Linux beta via the Anthropic apt repo on any Linux machine (with or without a TPM — the binding never uses it).
2. Sign in and start any Cowork session with an attached folder ("in the cloud" mode).
3. The session shows "Couldn't link this session to a computer, so attached folders can't be used"; main.log logs enclave key unavailable — refusing to resolve row-PK. Device-bridge tools are absent from the session.
4. Verify the root cause directly: grep -a "linux-not-yet-supported" /usr/lib/claude-desktop/resources/app.asar.unpacked/node_modules/@ant/claude-native/claude-native-binding.node → the stub failure string is present in every Linux build.

(Local "On your computer" VM sessions still work — only cloud-session↔computer linking is affected.)

Claude Model

None

Is this a regression?

I don't know

Last Working Version

Linking worked until ~2026-07-17/19 on 1.18286.2, then broke on the same client version with no local change — consistent with a server-side td-v2 rollout, not a client version regression.

Claude Code Version

Desktop-bundled CCD/SDK: 2.1.215 (was 2.1.202 when the issue started). Claude Desktop (Linux, apt): 1.22209.3 (issue began on 1.18286.2).

Platform

Anthropic API

Operating System

Ubuntu/Debian Linux

Terminal/Shell

Other

Additional Information

• Host: Samsung Galaxy Book (x64), 16 GB RAM, Ubuntu 24.04, GNOME 46 (Wayland), kernel 6.17.0-40-generic; TPM 2.0 present (/dev/tpm0, /dev/tpmrm0)
• qemu-system-x86 8.2.2, virtiofsd 1.10.0, ovmf 2024.02; local VM verified healthy (boots, guest connects, API reachable)
• gnome-keyring running and unlocked during all failures — not a locked-keyring problem

Likely the common root cause behind several open reports:

• #78671 — Linux, signCreateSessionBind not_registered, silent unbound fallback: same failure, root cause not identified there
• #77348 — Linux, exact same banner text (that machine also has a separate VM-start problem; the banner part is this bug)
• #78727 — Windows, same enclave key unavailable — refusing to resolve row-PK warning after the 1.22209 auto-update: likely a sibling failure mode of the same registry/attestation rollout

This report adds: the shipped-binary evidence that the Linux native module cannot ever produce the enclave key (linux-not-yet-supported stub, no TPM/libsecret linkage), which explains why no local remediation (state reset, re-registration, sign-out/in, reinstall) can work.