[BUG] VSCode/VSCodium extension: Web section lists archived sessions — fetchRemoteSessions() sends no filter and flattens session_status to "idle"

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

The extension's Web section lists archived (closed) cloud sessions alongside active ones, with no visual distinction between them. Once you've archived a handful of web sessions for a repo, the list becomes unusable for finding the sessions that are actually still open.

The cause is in fetchRemoteSessions() in the shipped extension.js. It calls GET /v1/sessions with no query parameters, applies only a git-repository filter to the response, and then collapses every non-running status into "idle":

status: l.session_status === "running" ? "running" : "idle"

So whatever field carries archived state is discarded before the webview ever receives it. The extension has no concept of archival anywhere in its session-listing path.

What Should Happen?

Archived sessions should be excluded from the Web list by default — or at minimum visually marked, or placed behind a show/hide toggle, matching how the web app itself treats them.

The Web section should show sessions that are actually still open.

Error Messages/Logs

Steps to Reproduce

1. From claude.ai/code, start several web sessions against a repo that you also have open in VSCodium (or VS Code).
2. Archive/close some of those sessions in the web app.
3. In VSCodium, open the Claude Code extension and go to the Web section.
4. The archived sessions are still listed, rendered identically to the open ones.

Expected: archived sessions are excluded, or at least distinguishable.
Actual: every session the API returns for the current repo is listed, with no way to tell archived from active.

This is not local state. On the reporting machine:

• The extension has no globalStorage directory — ~/.vscodium-server/data/User/globalStorage/ contains only vscode.json-language-features.
• No session-list cache file exists anywhere under the extension's storage.
• listRemoteSessions() -> fetchRemoteSessions() performs a live HTTP request on every invocation; there is no memoization or persisted list.

So there is nothing a user can clear, reset, or reinstall. The list is exactly what the endpoint returns, minus the repo filter.

Claude Model

None

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.222 (Claude Code)

Platform

Anthropic API

Operating System

Ubuntu/Debian Linux

Terminal/Shell

Other

Additional Information

Environment

| | |
| --- | --- |
| Extension | anthropic.claude-code 2.1.222 (linux-x64) — latest; bug also present in 2.1.220, where it was found |
| Editor | VSCodium 1.126.04524 (4c0b0c6cc561d2d3636d1ec250935431876ce4dc, x64), Remote-SSH server install |
| Claude Code CLI | 2.1.222 |
| OS | Ubuntu 26.04 LTS, kernel 7.0.0-28-generic |

Root cause

Verified against the current release: I pulled the 2.1.222 linux-x64 VSIX from Open VSX and compared it to the installed 2.1.220. fetchRemoteSessions() is logically identical in both — only minifier identifiers differ (to()→ro(), B_e→ove, gA→yA, hA→vA, q_e→sve). The snippet below is from 2.1.220; 2.1.222 differs only in those names.

From extension.js in the shipped extension (minified; reformatted below, identifiers as-shipped):

async fetchRemoteSessions() {
  let e = await this.prepareApiRequest();
  if (!e) throw Error("Failed to connect to remote server");
  let { accessToken: t, orgUUID: r } = e,
      n = `${to().BASE_API_URL}/v1/sessions`;          // <-- no query params
  try {
    let i = { ...B_e(t), "anthropic-beta": "ccr-byoc-2025-07-29", "x-organization-uuid": r },
        o = await gA(n, { headers: i, timeout: 15000, proxy: !1 });
    if (o.status !== 200) { /* ... */ return [] }

    let s = await this.detectCurrentRepository(), a;
    if (s)
      a = o.data.data.filter((l) => {                  // <-- only filter: git repo URL match
        let u = l.session_context.sources.find((p) => p.type === "git_repository");
        if (!u?.url) return !1;
        return hA(u.url) === s
      });
    else a = o.data.data;                              // <-- no repo detected: everything passes

    let c = a.map((l) => {
      /* ... */
      return {
        id: l.id,
        lastModified: new Date(l.updated_at).getTime(),
        summary: l.title || "Untitled",
        isRemote: !0,
        remoteRepo: d,
        status: l.session_status === "running" ? "running" : "idle"   // <-- archived flattened to "idle"
      }
    });
    return this.logger.log(`Fetched ${c.length} remote sessions`), c
  } catch (i) { /* ... */ return [] }
}

Three concrete problems:

1. The request asks for everything. GET /v1/sessions is sent bare — no archived=false, no status filter, no pagination params.
2. The only client-side filter is repository identity. Archived state is never consulted. Note also that when no repository is detected, the else branch passes the entire unfiltered list through.
3. session_status is destroyed at the mapping step. The ternary folds all non-running states into one "idle" bucket. Even if the API distinguishes archived sessions via session_status, the webview cannot tell — it only ever receives "running" or "idle".

The extension has no concept of archival in this code path. Grepping the shipped bundle for archiv* gives 36 hits in extension.js and 5 in webview/index.js — identical counts in 2.1.220 and 2.1.222. All are unrelated to the Web list: mime-db entries (application/java-archive, application/vnd.android.package-archive), the archive codicon, SQL/ABAP keyword lists (pg_ls_archive_statusdir), and the bundled Anthropic SDK's managed-agents archive() methods.

Worth noting for triage: that bundled SDK does include POST /v1/sessions/{id}/archive, but it sits on a different API surface — ?beta=true with anthropic-beta: managed-agents-2026-04-01 — whereas fetchRemoteSessions() uses anthropic-beta: ccr-byoc-2025-07-29. I have not established whether these two /v1/sessions surfaces are the same resource; if they are, the archived state may already be reachable.

Open question for triage

I could not verify whether GET /v1/sessions even exposes an archived flag — that would require calling the endpoint with the account's OAuth token, which I did not do. So this is one of two cases, and triage should confirm which:

• (a) The response carries archived state (in session_status or a sibling field) and the extension discards it → pure client-side fix: preserve session_status verbatim through the mapping and filter archived sessions out of the list.
• (b) The endpoint has no archived filter or indicator → needs a server-side parameter (e.g. ?archived=false) before the extension can do anything.

Either way the fix is upstream; nothing is actionable on the user's machine.

Suggested fix

Minimally: stop collapsing session_status, and exclude archived sessions from the Web list by default. A toggle to show archived sessions would match the web app's behavior.

Related but distinct

• #78230 — archived sessions inaccessible on web when all are archived (opposite direction)
• #24534 — archived sessions not visible in the Desktop Archive filter (Windows)
• #81466 — desktop sessions auto-archive and become invisible on mobile

Those are all "archived sessions can't be seen." This one is "archived sessions can't be un-seen," in the VS Code/VSCodium extension specifically.

On #68777 and its family, which GitHub surfaces as similar: #68777, #53082, #29264, #26908 and #27496 all report the inverse symptom — the Web tab shows no sessions at all ("No web sessions yet"; #29264 pins it to list_remote_sessions returning 404). This report is that the Web tab shows too many: sessions the user already archived. Same function, opposite failure, disjoint fixes — excluding archived sessions from the list does nothing for a list that is empty, and making an empty list populate does nothing about archived entries appearing in it. #68777 was closed not planned by the staleness bot on 2026-07-30 without ever being diagnosed, so there is also no resolution there to inherit.