[BUG/UX] Accepting the in-app "connect GitHub" recommendation made cloud the default session type, silently removing local filesystem and hardware access
Filed as plain markdown rather than through the issue form: the body exceeds the form prefill limit. Preflight: searched existing issues (no match found for this behaviour); single bug report; on the current latest desktop build.
What's Wrong?
I am building monogokoro — a LeRobot fork adding a
reflex layer to an SO-101 robot arm — and I am building it fast, with Claude Code as the main
pair. Servos on a serial bus at 1 kHz, two USB cameras, a Thunderbolt eGPU, a realtime kernel.
It has been a genuinely good tool for this. That is the workload this report is about, and it
is exactly why the failure hurt.
I was shown an in-app recommendation to connect GitHub. I accepted it. After that, new sessions
defaulted to running in the cloud rather than on my machine.
The recommendation did not say that accepting it would change where my sessions execute.
What I lost, without being told I was losing it:
- The local filesystem. The project is never fully represented by its git remote — datasets,
calibration logs, telemetry captures and measurement output are local and untracked.
~/.claude/projects/<project>/memory/. Persistent memory built up over weeks. These were
never deleted — all 71 files are on disk, the oldest dated two weeks before the incident. The
cloud environment simply could not reach them. But from where I sat there was no difference:
the assistant had lost its memory, and nothing said why.
- The hardware. Servos, cameras, the eGPU, and a daemon holding realtime capabilities. None
of that exists in a cloud sandbox.
For most projects a cloud sandbox is reasonable or even better: the work is reading and writing
source, and the sandbox does that fine. For a project whose value is in touching physical
hardware, a cloud session is not a degraded local session. It is a different product that cannot
do the job at all. Every measurement here comes from a servo, a camera, or a power rail on the
desk next to me. Move execution off this machine and what remains is "read the source code" —
the one part I did not need help with.
The failure mode is also quiet. Nothing said "you no longer have local access." Claude simply
could not find files it had been reading an hour earlier, and I had to work out why.
What Should Happen?
- Say what the recommendation costs before I accept it. If connecting GitHub changes the
default execution location, that sentence belongs in the prompt, not in the docs.
- Don't change the default execution location as a side effect of connecting an integration.
Connecting GitHub and choosing where code runs are two different decisions.
- Make the current session's execution location visible. Local vs cloud should be readable
at a glance, not inferred from a tool failing.
- Fail loudly when a cloud session opens on a project with local-only state. The presence of
~/.claude/projects/<...>/memory/, or an untracked working tree, is a strong signal that the
user did not mean to leave the machine.
Steps to Reproduce
- Use Claude Code in the Claude desktop app (Code tab) on a local project that depends on
local-only state — untracked files, attached hardware, or a populated
~/.claude/projects/<project>/memory/ directory.
- Accept the in-app recommendation to connect GitHub.
- Start a new session on the same project.
- Observed: the session runs in the cloud. It cannot read the working tree, cannot read the
memory directory, and cannot reach attached hardware. No warning is shown at any point that
execution has moved off the local machine.
I cannot give the exact wording of step 2's prompt — see "Additional Information".
Environment
| | |
|---|---|
| Claude Model | Opus |
| Is this a regression? | I don't know |
| Claude Code Version | claude-desktop 1.52386.3 (deb; no separate CLI installed) — encountered on 1.49585.0, see note below |
| Platform | Anthropic API |
| Operating System | Ubuntu/Debian Linux (Ubuntu 26.04.1, realtime kernel 7.0.0-31-realtime) |
| Terminal/Shell | Other — Claude desktop app, Code tab (not a terminal) |
Additional Information
Repository demonstrating the workload: https://github.com/s-tory/monogokoro — public. The
hardware abstraction under src/lerobot/{motors,cameras,robots} and the realtime daemon are the
parts that cannot exist in a cloud sandbox, if you want to see the concrete shape of it.
Version. I hit this on claude-desktop 1.49585.0. I have since upgraded to 1.52386.3
(current latest on the apt stable channel). I have not retested on the new version and cannot:
the recommendation is a one-time prompt I already accepted, and I deleted the cloud session. So I
cannot say whether this is still present in 1.52386.3. If it has already been changed, treat
this as a report about the older version and close it.
What I did not verify. I cannot recover the exact wording of the recommendation: I took no
screenshot, and I have since deleted the cloud session. I also have not confirmed from the
outside which of the several cloud-capable modes I was placed in. What I am reporting is the
observed behaviour: I accepted a GitHub connection, and afterwards sessions ran somewhere that
could not see my files, my memory directory, or my hardware.
I switched back to local and everything returned, with nothing lost. The damage was time, and
the hour I spent believing my local state had been destroyed.