[BUG] /btw side-channel gives explanations the main session can't see, verify, or correct
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?
Body:
Summary
During a long working session in a local project, I used /btw to ask a quick side question. The answer included a confident-sounding explanation that turned out to be wrong, and — because the main session has no visibility into what was said in /btw — it couldn't verify, cite, or correct it. Reconciling the two took several turns of back-and-forth and direct code re-verification that shouldn't have been necessary.
What happened
- I asked (via /btw) why a particular value wasn't appearing during a test run.
- The response attributed it to the producing component "not being configured."
- I had independently verified it was configured, and reported the discrepancy to the main session.
- The main session had no access to what was actually said in /btw, and initially couldn't reconcile the conflict at all — it took multiple turns and direct code inspection to determine the real cause (the component simply wasn't included in that particular run's active set — a selection question, unrelated to configuration).
- A separate /btw exchange, about a performance/timing question, had the same problem: the main session couldn't verify or reproduce the explanation it was told I'd been given, and had to re-derive the real answer from scratch before the confusion resolved.
Why this is a problem
- The main session and /btw appear to share no visibility into each other's exchanges — neither can see, cite, or correct what the other said.
- When the two disagree, there's no way to resolve it except discarding both and re-deriving from scratch, which defeats the point of asking a quick side question in the first place.
- Both surfaces present as "Claude," so there's no clear signal to the user about which is authoritative, or whether a /btw answer has been grounded in the actual working context at all.
Context
Claude Code CLI, extended session doing pipeline architecture/refactoring work with heavy code verification against a real repo.
What Should Happen?
Suggestion (not a demand — I don't know the design constraints)
- Give the main session at least read access to recent /btw exchanges in the same working session, so it can verify or correct a claim instead of reconstructing it blind.
- Or, surface /btw answers as explicitly provisional/ungrounded when they haven't been checked against the actual session context, rather than presenting them with the same confidence as the main session's own verified answers.
Error Messages/Logs
Steps to Reproduce
Start a long running test run - I was using a local pre-commit skill to sniff-test that nothing unexpected was broken prior to a commit.
Use /btw to question something seen during the test - In my case, an opencv screen opened unexpectedly and showed unexpected results.
The /btw response was confident but total BS. It asserted modules that had been excluded from the test were in fact running, and then used that fact to explain a performance issue. Module not running, performance issues was something else.
After the sniff-test finished and I could prompt claude normally, we spent an hour trying to sort out what the test actually covered and what was broken.
Claude Model
Sonnet (default)
Is this a regression?
I don't know
Last Working Version
_No response_
Claude Code Version
2.1.220 (Claude Code)
Platform
Anthropic API
Operating System
macOS
Terminal/Shell
Other
Additional Information
_No response_