Claude Code desktop can resume CLI sessions with /resume

Claude Code's developer account says a terminal session can continue inside the desktop app with the conversation and context still attached.

On August 28, 2026, @ClaudeDevs posted: "You can now resume your terminal sessions in the Claude Code desktop app." Then: "Type /resume to pick any session you started from the CLI. The session continues in the app with the full conversation and context intact."

That is a cross-surface claim, not another recap of the CLI session picker. Work that began in a terminal is supposed to pick up in the desktop Code tab without losing history.

What the post says

The post is three sentences. It does not name a Claude Code version, a desktop app version, or a platform. It does not list excluded session types. It does say "any session you started from the CLI," and it does say the full conversation and context stay intact.

Until the HTML documentation says the same thing, that post is the public claim.

Why the silo mattered

In Claude Code, a session is a saved conversation tied to a project directory, stored locally as you work so you can resume, branch, or switch tasks. The CLI already had ways to come back to one. The desktop Code tab already had a sidebar of sessions you can run in parallel. What was missing was a documented way to cross from the terminal into the app with the same thread.

The two surfaces are good at different jobs. The CLI is the tight loop: claude --resume, named sessions, scripts, claude -p. The Code tab is the wider bench: diffs, a browser pane, an integrated terminal, split views, Git worktrees. If the histories do not meet, you stay in the terminal or you re-explain the work in the app.

@ClaudeDevs says they now meet in one direction: CLI toward desktop, through /resume.

The docs still describe two histories

The sessions documentation still states the old split. It says the desktop app, Claude Code on the web, and the VS Code extension each maintain their own session history, and that the page covers the CLI.

Further down, it says that once you name a session through a CLI route or from claude.ai, you return to it with claude --resume <name> or /resume <name>. It then adds that a desktop-app session resumes in the app, which keeps its own session history.

That still reads as separate stores. In those same CLI docs, /resume is an in-session switcher: it opens the session picker or jumps to a named conversation. It is not described as a desktop import.

The desktop documentation presents each Code tab conversation as a session with its own chat history, project folder, and code changes, listed in the sidebar so you can run several at once. It points CLI users to a comparison of what carries over. It does not document typing /resume in the app to continue a terminal session.

The account and the HTML currently disagree. Read the tweet as the claim, and the docs as lagging.

What CLI resume already restores

On the CLI, sessions save continuously to local transcript files. Documented entry points include:

claude --continue — the most recent interactive session in the current directory
claude --resume — the session picker
claude --resume <name> — a named session
/resume — switch conversations from inside an active session

A resumed CLI session restores the full conversation, including tool calls and results. Other state can come back too: the model, with listed exceptions when it has been retired, blocked by availableModels, overridden at launch, or tied to a provider deployment ID; the agent, if the session started as one; permission mode, on some terminal resume paths; an active goal; and scheduled tasks that have not expired. Flags such as --mcp-config, --settings, --plugin-dir, --fallback-model, and directories added with --add-dir are not restored. You pass them again.

The picker also skips work. Sessions created with claude -p or the Agent SDK stay out of the picker and out of claude --continue, though you can still resume one by session ID. claude --continue skips background sessions and sessions whose first prompt was /loop.

None of those rules appear in the @ClaudeDevs post. Whether desktop /resume honors them is unknown.

What the Code tab already does with sessions

The Claude Desktop app's Code tab is a session environment of its own. Before the first message you choose an environment — local, cloud, SSH, or WSL on Windows — plus a project folder, a model, and a permission mode. The app reads the same settings files as the CLI, including permission defaults.

Shared settings are not shared history. Settings tell a new session how to behave. History is the work you already did. The tweet is about history.

You can run several desktop sessions at once from the sidebar. For Git repositories, each session gets an isolated copy through Git worktrees. You can split two sessions on screen and let Claude check on other sessions. That is a strong parallel-work surface, and the reason importing a CLI thread into that sidebar would change a daily workflow, if it behaves as the post describes.

The post does not say how a resumed CLI session appears among those sidebar sessions, whether it keeps the CLI permission mode, or whether cloud, SSH, and WSL environments in the Code tab can host it.

If you already keep long-running work in the terminal and review it in the app, try the handoff on a disposable session before you trust it with something you cannot rebuild. Start a short CLI session, leave a distinctive message in it, open the desktop Code tab, and type /resume. Look for that session. If the conversation is there with context intact, the post is doing what it says. If the picker still only shows desktop-native threads, the silo language in the docs is still the behavior.

Then watch the sessions documentation and the desktop documentation for the "own session history" wording to change.