Claude CLI usage probe mints a new empty account session per probe, polluting the claude.ai session list (dozens of <host>-<word>-<word> entries)

[elpinguinofrio]

Summary

CodexBar's Claude CLI usage probe (ClaudeCLISession, working dir ~/Library/Application Support/CodexBar/ClaudeProbe) launches a fresh headless claude CLI session on every probe. Each launch registers a new, permanently-empty session on the user's Anthropic account. Over weeks this pollutes the claude.ai / Claude desktop session list with dozens of entries auto-named <hostname>-<adjective>-<noun> (e.g. macosvm-snug-moore, macosvm-typed-lovelace, macosvm-eager-conway) — 36+ on my account so far, accumulating at roughly one per day since the ClaudeProbe workdir was created (Jun 7).

The user has no way to tell these come from CodexBar — they look like a rogue agent spawning sessions, which is how I initially investigated it.

Environment

• CodexBar 0.43.0 (104), installed in /Applications, launched as Login Item
• Claude Code CLI 2.1.212, ~/.local/bin/claude
• macOS 15.7.3 (arm64), hostname macOSvm
• Claude source: auto (OAuth path failing → CLI fallback active; claudeOAuthDelegatedRefreshLastAttemptAtV1 = Jul 8)

Evidence

• ~/.claude/projects/-Users-elpinguino-Library-Application-Support-CodexBar-ClaudeProbe/ is created when the probe runs — but contains zero transcripts (probes send no messages), so every probe leaves a nameless server-side session.
• Cross-referencing ~/.claude/session-env/ (one entry per locally-started session) against ~/.claude/projects/ transcripts: 11 transcript-less "phantom" sessions Jul 8–17, ~1/day, the last at 10:50 today.
• Prefs contain claudeCLIUsageRateLimitBlockedUntilV1 — the probe even got rate-limited by Anthropic today, so the probe frequency is also hitting API limits.
• All words in the generated session names match the adjective/noun word lists embedded in the claude CLI binary (30/30 from my session list screenshot), confirming these are CLI-minted untitled sessions, not another device.

Expected

Usage probing should not create durable account-side sessions, or at minimum should reuse one persistent session. Options that would fix it:

1. Reuse a single session (--resume/fixed --session-id) for all probes instead of minting a new one each time.
2. If the CLI/API gains a way to mark a session ephemeral/unlisted, use it.
3. Document the behavior and surface it in the UI ("Claude CLI probing creates sessions named -…") so users don't chase ghosts.

Actual

Every CLI probe = one new permanent <host>-<random>-<random> session in the account list; no cleanup, no attribution.

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed July 16, 2026, 11:14 PM ET / July 17, 2026, 03:14 UTC.

Summary
This appears to be a valid current-main bug: CodexBar still launches an interactive Claude CLI process for passive usage probing without an ephemeral or reusable session control, and the prior local-artifact cleanup does not address account-side sessions. Keep it open for a maintainer-approved privacy-safe probe design and live verification against a real Claude account.

Reproducibility: no. this review did not independently reproduce the account-side session creation on a real Claude account. The current launch path and the reporter's detailed local/account correlation make it highly source-reproducible, but repository policy discourages unsolicited live provider probes.

Ways to help us reproduce this

• Add a screenshot or short recording showing the behavior.
• Add expected vs actual behavior.
• Include redacted logs or terminal output.

Next step
A maintainer should first choose the privacy-safe Claude fallback contract, after which the implementation and validation path are bounded.

Maintainer decision needed

• Question: Should CodexBar keep the Claude CLI fallback by reusing an account-scoped probe session, or disable/opt in that fallback until Anthropic provides a verified ephemeral usage-probe path?
• Rationale: Both choices affect provider availability and remote account state, and repository policy requires explicit sign-off for provider authentication, remote data handling, and privacy-sensitive behavior.
• Likely owner: steipete — The choice changes Claude provider fallback behavior and remote account-state handling, areas reserved for explicit project sign-off.
• Options:
  • Reuse one scoped session (recommended): Keep CLI usage fallback but derive and reuse a probe-only session identifier scoped to the active Claude credential, with upgrade and account-switch tests.
  • Disable passive CLI probing: Stop automatic interactive CLI launches and require OAuth or explicit user action, avoiding remote session creation at the cost of reduced fallback coverage.
  • Document current behavior: Retain the current launch behavior but clearly disclose the generated sessions, which reduces confusion without preventing account-list pollution or rate-limit use.

Review details

Best possible solution:

Make passive Claude probing side-effect free; if the CLI cannot create an ephemeral session, use one deterministic account-scoped probe session with safe credential-change handling, focused launch tests, and redacted live proof that repeated refreshes do not add account sessions.

Do we have a high-confidence way to reproduce the issue?

No, this review did not independently reproduce the account-side session creation on a real Claude account. The current launch path and the reporter's detailed local/account correlation make it highly source-reproducible, but repository policy discourages unsolicited live provider probes.

Is this the best way to solve the issue?

Unclear: reusing a fixed session is the narrowest likely repair, but it is only safe if scoped to the active credential and proven not to mix accounts or retain unwanted content. Disabling passive CLI fallback is the safer fallback if those guarantees cannot be established.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• A constant session identifier that is not scoped to the active Claude account could mix probe state across credential changes or accounts.
• Disabling the CLI fallback outright could leave users without Claude usage data when OAuth probing is unavailable.
• The account-side semantics of --session-id, --resume, and empty interactive launches may vary by Claude CLI version and require redacted live-account proof.

Codex review notes: model internal, reasoning high; reviewed against 547b2789e4c5.

Label changes

Label changes:

• add P2: The bug repeatedly pollutes a user's Claude account session list and can consume rate limits, but it does not make CodexBar's core runtime unusable.
• add impact:ux-friction: Unattributed generated sessions cause avoidable user confusion and investigation burden while the application otherwise remains usable.
• add issue-rating: 🦞 diamond lobster: Current issue advisory state selects this label.
• add clawsweeper:source-repro: Current issue advisory state selects this label.
• add clawsweeper:no-new-fix-pr: Current issue advisory state selects this label.
• add clawsweeper:fix-shape-clear: Current issue advisory state selects this label.
• add clawsweeper:needs-maintainer-review: Current issue advisory state selects this label.
• add clawsweeper:needs-product-decision: Current issue advisory state selects this label.

Label justifications:

• P2: The bug repeatedly pollutes a user's Claude account session list and can consume rate limits, but it does not make CodexBar's core runtime unusable.
• impact:ux-friction: Unattributed generated sessions cause avoidable user confusion and investigation burden while the application otherwise remains usable.

Evidence reviewed

Acceptance criteria:

• Add focused tests around Claude CLI launch arguments and deterministic account-scoped session identity without invoking real credentials.
• Run swift test --filter ClaudeCLISessionTests or the closest focused Claude probe test target.
• Run make test and make check after the implementation is approved.
• With explicit permission, capture redacted live proof showing the Claude session list before and after multiple scheduled probes and an account switch.

What I checked:

• Current probe launch: At current main, ClaudeCLISession creates the dedicated ClaudeProbe working directory and starts the Claude binary with CodexBar's probe environment, but no fixed session identifier, resume argument, or ephemeral-session control is present in the launch path. (Sources/CodexBarCore/Providers/Claude/ClaudeCLISession.swift:87, 547b2789e4c5)
• Probe lifecycle: ClaudeStatusProbe uses ClaudeCLISession for CLI-backed usage collection, so scheduled passive refreshes repeatedly exercise this session-start path when OAuth is unavailable or falls back to the CLI. (Sources/CodexBarCore/Providers/Claude/ClaudeStatusProbe.swift, 547b2789e4c5)
• Prior cleanup has a narrower boundary: Release v0.32.5 added removal of transient local ClaudeProbe session artifacts after each probe, associated with ClaudeProbe poll creates persistent Claude Code sessions every ~2 min (since CC v2.1.160) #1301; that cleanup does not establish deletion or suppression of durable account-side sessions. (Sources/CodexBarCore/Providers/Claude/ClaudeProbeSessionArtifactCleaner.swift, 2e83a34)
• Reporter reproduction evidence: The report correlates the dedicated ClaudeProbe project directory, transcript-free local session metadata, generated Claude CLI session names, probe cadence, and rate-limit state on CodexBar v0.43.0. This is detailed external evidence, although the account-side behavior was not independently exercised during this read-only review.
• Current release boundary: The reported release is v0.43.0, and current main still contains the relevant uncontrolled CLI session-start behavior; no supplied or discovered merged fix owns this account-session pollution problem. (Sources/CodexBarCore/Providers/Claude/ClaudeCLISession.swift:87, 547b2789e4c5)
• Vision alignment: VISION.md defines CodexBar as a privacy-first provider usage monitor while requiring explicit sign-off for provider authentication, remote data handling, and privacy-affecting changes. Avoiding unexplained remote session creation fits that direction, but the exact fallback behavior needs maintainer approval. (VISION.md:7, 547b2789e4c5)

Likely related people:

• steipete: Repository and release history show sustained ownership of the Claude provider and CLI-probe architecture, and VISION.md reserves provider-authentication and privacy-sensitive direction for explicit sign-off. (role: recent area contributor and likely decision owner; confidence: high; commits: 547b2789e4c5, 2e83a34; files: Sources/CodexBarCore/Providers/Claude/ClaudeCLISession.swift, Sources/CodexBarCore/Providers/Claude/ClaudeStatusProbe.swift, VISION.md)
• Yuxin-Qiao: Recent merged work associated with the Claude CLI usage fallback makes this contributor relevant to the behavior and validation constraints of the probe path. (role: recent Claude CLI usage-path contributor; confidence: medium; commits: 333d584; files: Sources/CodexBarCore/Providers/Claude/ClaudeStatusProbe.swift, Sources/CodexBarCore/Providers/Claude/ClaudeCLISession.swift)

How this review workflow works

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.

[devYRPauli]

Root cause: ClaudeCLISession.ensureStarted (Sources/CodexBarCore/Providers/Claude/ClaudeCLISession.swift:271-330) launches claude --allowed-tools "" with no --resume or --session-id and no ephemeral-session flag. Whenever the cached PTY process isn't already running (app restart, probe torn down between refreshes), this mints a new server-side session under the ClaudeProbe workdir. Confirmed via grep: no session-id or resume handling exists in this file today.

Recommended fix: persist one deterministic, credential-scoped probe session id (UUID tied to the active account), pass it via --resume/--session-id on every launch, regenerate on account switch or CLI rejection. This is the "reuse one scoped session" option from the automated review.

Alternatives:

• Disable passive CLI probing, require OAuth or explicit user action. Safer, drops fallback coverage when OAuth is unavailable.
• Document current behavior only. Does not stop the pollution.

Caveat: whether --resume/--session-id actually suppress new account-side sessions is unverified here and needs a live-account check. The probe scrapes usage from an interactive PTY transcript, so dropping session creation entirely looks infeasible without a non-interactive usage command.

Which direction do you prefer before we open a PR?

[steipete]

Fixed by #2263 and merged as cfb7b8036087cc1186b963ada7bec2ce9efa71e2.

The usage probe now reuses one persisted Claude session UUID for direct and watchdog launches instead of allowing every cold CLI launch to mint a new account session. Crash-stale local probe transcripts are cleared before launch, and persistence failure uses one process-local UUID rather than a global fixed identifier.

Proof: 12 focused tests passed across ClaudeCLISessionTests, ClaudeDirectUsageFallbackTests, and ClaudeProbeWorkingDirectoryTests; make check passed; autoreview was clean; all PR checks passed, including both macOS test shards and both Linux builds.

An account-side before/after session count was unavailable here because the working Claude CLI is logged out and the newer global wrapper cannot load its native optional package. The limitation is recorded on the PR; no live result was inferred.