Unsupported platform: linux-x64 thrown from getHostPlatform() during session init; cascading binary/version mismatches downstream

[Crono141]

Area

Cowork session (spawn / spawn fails)

What happened?

Description

On a fresh install against current Claude Desktop builds (SDK 2.1.119), prompt submission fails with Unsupported platform: linux-x64. The existing platform-gate patch in enable-cowork.py is being applied successfully, but the error originates from a different function (getHostPlatform()) that's called downstream during prepare() on every session init.

After patching that, two further issues surface in sequence — one related to platform spoofing causing a Mach-O binary to be downloaded, and one related to CLI version drift. Documenting all three together since they're effectively a single broken pipeline.

Environment

• Distro: CachyOS (Arch-based)
• claude-cowork-linux: installed via [method — AUR/install.sh/etc.]
• Claude Desktop version: 1.1.4498
• claude-code SDK version (downloaded): 2.1.119
• Local claude binary version (initial): 2.1.91

Repro

1. Install per README.
2. Launch claude-cowork, sign in, point at a working folder.
3. Submit any prompt.
4. Session fails to initialize.

Issue 1: getHostPlatform() throws on Linux

enable-cowork.py patches the platform-availability gate and applies cleanly (/*cowork-patched*/ marker present). However, prepare() calls getHostTarget() which calls getHostPlatform(), and that function has its own platform check that only handles darwin and win32:

getHostPlatform(){const A=process.arch;if(process.platform==="darwin")return A==="arm64"?"darwin-arm64":"darwin-x64";if(process.platform==="win32")return A==="arm64"?"win32-arm64":"win32-x64";throw new Error(`Unsupported platform: ${process.platform}-${A}`)}

Stack trace from ~/.config/Claude/logs/main.log:

Error: Unsupported platform: linux-x64
    at HSr.getHostPlatform (/usr/lib/claude-cowork/app.asar/.vite/build/index.js:468:58573)
    at HSr.getHostTarget (...:468:58668)
    at HSr.prepare (...:468:65575)
    at async eP.doSessionInitialization (...:5951:62561)

Workaround: sed-patch the function to add a linux branch returning "darwin-x64", then repack the asar. Electron's v8 code cache must be cleared (~/.config/Claude/Code Cache, GPUCache, CachedData) for the patch to take effect — otherwise the cached bytecode keeps throwing at the original line/column even though the source is patched.

Issue 2: macOS Mach-O binary downloaded into SDK directory

Once getHostPlatform() returns "darwin-x64", installSdk() downloads a macOS binary:

$ file ~/.config/Claude/claude-code/2.1.119/claude
Mach-O 64-bit x86_64 executable, flags:<NOUNDEFS|DYLDLINK|TWOLEVEL|BINDS_TO_WEAK|PIE|HAS_TLV_DESCRIPTORS>

Attempting to exec it fails with code 126:

[HostLoop] cli.js stderr: /home/joel/.config/Claude/claude-code/2.1.119/claude: /home/joel/.config/Claude/claude-code/2.1.119/claude: cannot execute binary file
Error: Claude Code process exited with code 126

The README mentions that launch.sh does a Mach-O fixup for the asar-internal Code tab binary, but that fixup doesn't extend to ~/.config/Claude/claude-code/<version>/, where installSdk() puts SDK binaries.

Workaround: symlink ~/.config/Claude/claude-code/<version>/claude to the local Linux claude binary (~/.local/bin/claude). Leave the .verified marker in place so the app doesn't try to re-download.

Issue 3: --effort xhigh flag rejected by older CLI versions

Claude Desktop 1.1.4498 passes --effort xhigh to the CLI. CLI version 2.1.91 only accepts low/medium/high/max:

[HostLoop] cli.js stderr: error: option '--effort <level>' argument 'xhigh' is invalid. It must be one of: low, medium, high, max
Error: Claude Code process exited with code 1

Updating the local claude to match the SDK version Desktop expects (2.1.119) resolved this. So in practice the symlink target also needs to be version-current.

Suggested fixes (in priority order)

1. Add a getHostPlatform patch step to enable-cowork.py. Auto-detect the function (similar to how the platform-gate function is found) and inject a Linux branch returning "darwin-x64". This is the actual blocker for Linux users on current builds — the existing platform-gate patch alone is not sufficient.
2. Extend the Mach-O detection in launch.sh to cover ~/.config/Claude/claude-code/<version>/. Same fixup logic as the asar-internal binary, but applied to whichever versioned SDK directory exists. Ideally check on every launch since installSdk() creates new directories as Claude Desktop bumps versions.
3. Document the CLI version requirement in the README/troubleshooting. Users need a Linux claude binary at least as new as the SDK version Claude Desktop downloads, otherwise CLI flag mismatches will fail sessions. Worth adding to --doctor.
4. Cache invalidation note. The asar patch alone isn't enough — Electron's v8 code cache must be cleared. Worth either documenting in troubleshooting or having install.sh wipe ~/.config/Claude/Code Cache etc. on completion.

Steps to reproduce

See Above

Relevant log output

See Above

Distro and desktop environment

See above

claude-cowork-linux version / commit

See above

Claude Desktop version (app.asar)

see above

Checklist

• I ran ./install.sh --doctor and included its output if relevant
• I checked the log file and redacted any tokens before pasting
• I searched existing issues and this isn't a duplicate

[michael-greider]

I got this squared away good sir thank u for the well formatted issue, saved me a lot of time when I had the platform error crash🫡

[Crono141]

No problem. I used Claude to fix Claude and it wrote up this report with everything we did to fix it, so I can't take too much credit. 😅

[johnzfitch]

Fixed in #102.

All three issues from your report are addressed:

1. getHostPlatform() throws on Linux → enable-cowork.py now patches the throw with return"darwin-x64" (based on @michael-greider's fix in fix: Session init issue #97  #98)
2. macOS Mach-O binary downloaded → installSdk() now downloads the correct Linux binary from downloads.claude.ai/.../linux-x64/claude.zst
3. --effort xhigh flag rejected → resolved by the SDK binary matching the Desktop version

Thank you for the detailed three-part diagnosis — this was the clearest bug report in the repo.

---

Generated by Claude Code