[BUG] [Claude Desktop / Linux] Cowork & Dispatch hang on infinite spinner — app opens its own storage directories with O_DIRECT, ext4 returns EINVAL

Correction — the placeholders in the path list above were stripped as HTML. The
affected directories are:

~/.config/Claude/vm_bundles/claudevm.bundle
~/.config/Claude/claude-code/2.1.246
~/.config/Claude/claude-code-sessions/<org>/<uuid>
~/.config/Claude/local-agent-mode-sessions/<org>/<uuid>
~/.config/Claude/local-agent-mode-sessions/<org>/<uuid>/rpm
~/.config/Claude/local-agent-mode-sessions/<org>/<uuid>/agent/local_ditto_<uuid>/outputs
~/.config/Claude/local-agent-mode-sessions/skills-plugin/<uuid>/<org>/skills

[error] Session initialization failed for local_ditto_<uuid>: EINVAL: invalid argument,
open '.../local-agent-mode-sessions/<org>/<uuid>/agent/local_ditto_<uuid>/outputs'
at async e.primeSessionDirs (…/index2.chunk-Dkhfb34G.js)

--- kernel-console.log ---
(29 bytes, blank lines only — guest never produced output; last written 2026-07-23)

--- also present, likely separate ---
[error] Electron safeStorage encryption is not available on this system, cannot store allowlist cache

Your strace line is the key to this, but I think it's pointing somewhere other than where it looks.

openat(AT_FDCWD, ".../vm_bundles/claudevm.bundle",
       O_RDONLY|O_DIRECT|O_LARGEFILE|O_CLOEXEC) = -1 EINVAL

The app never asked for O_DIRECT. It asked for O_DIRECTORY and passed the x86_64 value for
it. On aarch64 that value happens to mean O_DIRECT, so strace decoded a flag nobody wrote.

The private-directory helper is:

await mkdir(dir, { recursive: true, mode: 0o700 });
const fd = await open(dir, fs.constants.O_RDONLY
                         | (fs.constants.O_DIRECTORY ?? 0)
                         | (fs.constants.O_NOFOLLOW  ?? 0));

Perfectly reasonable code. The constants it reads are wrong. Measured inside Anthropic's own shipped
arm64 Electron (42.10.0 / Node 24.18.1, process.arch === "arm64"):

| constant | arm64 build reports | correct aarch64 value | |
|---|---|---|---|
| O_DIRECTORY | 65536 (0o200000) | 16384 (0o40000) | ← x86_64 value |
| O_NOFOLLOW | 131072 (0o400000) | 32768 (0o100000) | ← x86_64 value |
| O_DIRECT | 16384 (0o40000) | 65536 (0o200000) | ← x86_64 value |

The other 12 O_* flags I checked (O_RDONLY, O_WRONLY, O_RDWR, O_CREAT, O_EXCL, O_TRUNC,
O_APPEND, O_NONBLOCK, O_SYNC, O_DSYNC, O_NOCTTY, O_NOATIME) are all correct. Exactly
the three whose values differ between x86_64 and aarch64 are wrong, and all three carry the x86_64
value — the signature of node_constants.cc compiled against x86_64 fcntl.h while targeting
aarch64.

These constants rotate between the two architectures in the Linux uapi headers:

| constant | x86_64 | aarch64 |
|---|---|---|
| O_DIRECT | 0o40000 | 0o200000 |
| O_DIRECTORY | 0o200000 | 0o40000 |
| O_NOFOLLOW | 0o400000 | 0o100000 |
| O_LARGEFILE | 0o100000 | 0o400000 |

So the intended O_DIRECTORY (0o200000) is O_DIRECT on aarch64 — and O_DIRECT on a directory
is unconditionally EINVAL: do_dentry_open() rejects it because directory inodes have no
direct_IO in their address_space_operations. Not ext4-specific, not filesystem-specific, and no
mount option avoids it. Your O_LARGEFILE in that same strace line is the other half of the rotation
showing up.

Minimal repro, no Anthropic software involved

Plain kernel-level check, runs anywhere on aarch64:

import os
d = "/tmp/probe"; os.makedirs(d, exist_ok=True)

os.O_DIRECTORY, os.O_NOFOLLOW, os.O_DIRECT      # -> 0o40000, 0o100000, 0o200000 on aarch64

os.open(d, os.O_RDONLY | os.O_DIRECTORY | os.O_NOFOLLOW)   # OK      <- what the app means
os.open(d, os.O_RDONLY | 0o200000 | 0o400000)              # EINVAL  <- x86_64 values
os.open(d, os.O_RDONLY | os.O_DIRECT)                      # EINVAL  <- isolates the bit

Line 3 is the intent and it works. Line 4 is the effect and reproduces the exact error. Line 5
isolates the responsible bit.

To read the constants out of the shipped binary directly (runAsNode is fused off, so this needs a
throwaway copy): flip the first fuse byte after the sentinel dL7pKGdnNz796PbbjQWNKmHXBZaB9tsX from
0 to 1 in a copy of claude-desktop, place it beside the real resources/ (otherwise it aborts
with Invalid file descriptor to ICU data received), then:

ELECTRON_RUN_AS_NODE=1 ./claude-desktop-copy -e \
  'const c=require("fs").constants; console.log(process.arch, c.O_DIRECTORY, c.O_NOFOLLOW, c.O_DIRECT)'
# arm64 65536 131072 16384      <- x86_64 values on an arm64 build

This is one bug, not three

I think this also accounts for #89850 and #90354. Same helper, same three constants:

• #90354 proposes that the binary filename resolves to an empty string, so the downloader opens

the version directory by accident. The observable is identical — open() on the directory, EINVAL
— but the filename is fine; the directory is opened deliberately, to chmod it safely, and it's
the flags that are wrong.

• #89850 reports the bare EINVAL on arm64 with no root cause. Same helper.
• This issue is the same fault reached through the Cowork/Dispatch path.

downloadBinaryForTarget() calls the helper before it logs Downloading from … and before it
opens a socket, which is why the CLI download dies with zero network I/O and the 3-attempt retry loop
surfaces it as Download failed. Check your internet connection and try again. That message is
actively misleading and worth fixing on its own — it sent all three of us looking at the network
first.

Five subsystems share the helper, matching your directory list:

| subsystem | user-visible effect |
|---|---|
| [CCD] binary manager | Claude Code sessions cannot start (hard block) |
| [CCDScheduledTasks] | scheduled tasks never persist |
| [ScheduledTasks] | same, agent-mode side |
| [RemotePluginManager] | plugin sync fails every poll |
| [SkillsPlugin] | skills sync fails every poll |

Plus vm_bundles, which is the spinner you're seeing.

Fix

Derive the flags from the running platform's fs.constants rather than baked-in x86_64 numbers — or,
upstream of that, build node_constants.cc against the aarch64 headers so fs.constants is right for
every consumer, not just this call site.

I patched the asar locally to use the correct aarch64 values and all five subsystems plus the
Cowork/Dispatch bundle load came back green: the CLI downloads, sessions start, scheduled tasks
persist, and plugin/skills sync stops erroring. So the constants really are the whole story here —
nothing else needed changing.

Happy to test a candidate build on Asahi Linux (Apple M1) if that's useful.

Confirming this on a second arm64 machine, and adding two things this thread doesn't have yet: why the flag is O_DIRECT, and how much user data it destroys.

Still present in 1.40609.0

Same failure, newer build — claude-desktop 1.40609.0, aarch64 Linux, kernel 6.17 (NVIDIA DGX Spark, GB10), ext4 on NVMe. It survived at least two releases past the 1.37937.3 reported here. On this machine 1.18286.0 was fine, so the regression landed between those.

Root cause: x86-64 open() constants in the arm64 bundle

The app isn't asking for O_DIRECT — it's asking for O_DIRECTORY|O_NOFOLLOW using x86-64 numeric values, which decode to something else entirely on aarch64:

| Flag | x86-64 value | What that value means on aarch64 |
|---|---|---|
| O_DIRECTORY | 0o200000 (0x10000) | O_DIRECT |
| O_NOFOLLOW | 0o400000 (0x20000) | O_LARGEFILE |

(aarch64's own O_DIRECTORY is 0o40000, O_NOFOLLOW is 0o100000.)

That exactly reproduces the observed O_RDONLY|O_DIRECT|O_LARGEFILE — the intent was a safe directory open, and O_DIRECT on a directory is EINVAL. It also explains why every affected call site is a directory open, and why nothing else in the app misbehaves.

Suggested fix: use fs.constants.O_DIRECTORY / fs.constants.O_NOFOLLOW instead of baked-in numeric literals (or gate the literals on process.arch). Node already exposes the correct per-architecture values.

Severity: this silently destroys sessions, not just Cowork

On this machine the same bug hit ensureStorageDir → writeSessionToDisk 1,241 times over two days, with no error surfaced in the UI. Consequences:

• Sessions existed only in memory. The durable session list froze at the exact minute of the upgrade.
• An unrelated reboot then dropped ~36 hours of sessions — they vanished from the sidebar, and their claude.ai tiles were left permanently showing "Remote Control disconnected" because the local↔session mappings were never persisted.
• Nothing warns the user. The app looks completely healthy right up until a restart deletes the day's work.

Recovery was only possible because the CLI writes its own transcripts to ~/.claude/projects/ independently of the broken store — the app's log still had Mapping internal session <local_id> to CLI session <cli_id> lines, so the store records could be reconstructed and joined back to their claude.ai tiles by timestamp. Without that log, the sessions would simply be gone.

Worth flagging because a spinner in one tab and silent permanent data loss are very different priorities.

Workaround

An LD_PRELOAD shim that rewrites 0x10000|0x20000 back to O_DIRECTORY|O_NOFOLLOW, scoped to paths under ~/.config/Claude, fully restores session saving and goes inert once the constants are correct. app.asar integrity is fused, so patching the bundle isn't an option — which leaves ordinary users with no fix at all.