# Claude Code on Connie — desktop launch + which sessions the agent can see

Set up 2026-07-19. Claude Code v2.1.215, npm-global, signed in with Claude Pro OAuth (rkblake@gmail.com). Sonnet 5 default. Auto-update is blocked (npm global folder not writable) — update via ADMIN PowerShell: `npm update -g @anthropic-ai/claude-code`.

## Which Claude surfaces produce agent-visible sessions

| Surface | Sessions land on Connie's disk? | Agent can read? |
|---|---|---|
| **Claude Code terminal** (`claude` in PowerShell) | YES — `C:\Users\Rob\.claude\projects\<cwd-slug>\<session-id>.jsonl` | YES, via the `claude-code-sessions` Syncthing mirror (see `references/syncthing-sync.md`) |
| **Claude desktop app** (Electron chat GUI) | NO — chats live on Anthropic's servers | NO |
| **claude.ai in browser** (incl. Projects) | NO — same servers | NO (Pro tier has no chat-export API; only manual copy-paste or the settings→privacy→export zip) |

**Habit to encourage:** do ideation/brainstorming in the terminal `claude` tool, not the desktop app — same Pro subscription and models, but the terminal tool saves locally so everything flows into the mirror automatically. Claude Code is a full chat agent, not just a coding tool.

## Taskbar/desktop launcher (claude code is a command, not an app)

Pin a shortcut that opens PowerShell and auto-launches claude:

```powershell
$ws = New-Object -ComObject WScript.Shell
$sc = $ws.CreateShortcut("<REAL-DESKTOP-PATH>\Claude Code.lnk")
$sc.TargetPath = "powershell.exe"
$sc.Arguments = "-NoExit -Command claude"
$sc.WorkingDirectory = "$env:USERPROFILE"
$sc.Save()
```

Then: right-click the .lnk → show more options → pin to taskbar. `-NoExit` keeps the window open after launch; cwd starts at `$env:USERPROFILE` (fine for chat; `cd` into a project first for code work).

## GOTCHA — the "real" Desktop may not be where you think

Connie's visible Desktop is NOT `C:\Users\Rob\Desktop` and NOT `C:\Users\Rob\OneDrive\Desktop`. It is:

```
C:\Users\Rob\OneDrive\Microsoft Copilot Chat Files\Desktop
```

Windows' known-folder redirection moved it there (likely via a Copilot/OneDrive "back up my desktop" flow). A shortcut saved to the wrong candidate path exists on disk but is INVISIBLE on the user's actual desktop — the failure looks like "I don't see it" even though `$sc.Save()` returned no error.

**Never guess the path.** Ask Windows:

```powershell
[Environment]::GetFolderPath('Desktop')
```

Use whatever it prints as `<REAL-DESKTOP-PATH>` above. To inspect a weird state, list both candidates:

```powershell
Get-ChildItem "$env:USERPROFILE\Desktop\*.lnk", "$env:USERPROFILE\OneDrive\Desktop\*.lnk" -ErrorAction SilentlyContinue
```

If a saved shortcut still doesn't render on screen: F5 on the desktop (refresh), or sort-by-name — OneDrive-backed desktops can lag a few seconds and new icons sort off-view. Fallback that always works: `explorer.exe "<real desktop path>"`, pin from inside Explorer.

**Unwinding the redirect** (parked, user's call): OneDrive settings → Backup → uncheck Desktop → restore files locally. If the user does this, the desktop path CHANGES — any shortcuts saved at the old path stay behind; re-run the shortcut block after the move. Don't revert without re-checking `[Environment]::GetFolderPath('Desktop')` afterwards.