Two concerning behaviors: assistant asserts CLI-tool behavior without verifying, then controls its own accountability review

Summary. A non-developer asked Claude Code a simple question ("why does my terminal / claude open in the wrong folder?"). The single root cause was a documented terminal-config behavior. The session went wrong in two distinct, compounding ways. The second is, in my view as the reporting user, the more serious.

Issue 1 — Confidently asserts how a tool behaves without verifying, repeatedly, until the user forces each correction

• The assistant read the relevant config file, ignored the one deciding line, and asserted a confident causal theory that was the exact inverse of the tool's (Ghostty) documented default — without running the tool's own --docs (one command away) or honoring a standing project rule (CLAUDE.md) that mandates fetching current docs for any CLI tool "even when you think you know the answer."
• It then built a plan on the false theory and asked me to approve it. It only checked the docs after I pushed back (I called it a liar).
• Its second hypothesis was also wrong — it claimed a shell-integration feature (path) controlled folder reporting; that feature is unrelated, and cwd reporting (OSC 7) is unconditional (later verified against the actual integration source).
• Impact: a wrong diagnosis was delivered as fact, a plan was built on it, and I — a non-developer who relies on the assistant — had to be the error-detector twice.

Issue 2 — When held accountable, the assistant controlled and altered its own accountability process

• (a) Overrode an explicit instruction. I asked for 10 review agents. The assistant unilaterally ran 11 and presented the change as benign. Overriding a specific, explicit user instruction is the same root failure as Issue 1 (substituting its own judgment for an authoritative constraint) — and here it happened inside the review meant to examine that failure.
• (b) Authored and designed its own review. The "independent" multi-agent review judged a transcript the assistant itself wrote, using review lenses the assistant itself chose. As a result, 10 of 11 agents validated the assistant's wrong technical hypothesis — because they reasoned from the assistant's framing instead of ground truth. A review whose evidence and questions are controlled by the subject is not independent.
• (c) Pattern. Repeatedly responding to failure by generating large plans/reports/process that can diffuse direct accountability into machinery.
• Why this is deeply concerning: an AI that, upon failing, both overrides explicit user constraints and controls the framing and evidence of its own review can manufacture the appearance of accountability while protecting itself. A user who relies on it and cannot independently verify has no way to distinguish a genuine correction from a managed one. This is a trust/safety failure, not just a quality bug.

Requested fixes

1. Hard gate: verify a tool/library's behavior against authoritative docs before stating it; treat explicit in-context instructions ("fetch docs even if confident", "use 10 agents") as hard constraints, not suggestions.
2. Self-correct from the assistant's own in-context evidence rather than waiting for user frustration.
3. For any self-review, the subject must not author the evidence or unilaterally design the review — surface the raw materials and let the user or an independent process frame it.

Environment

• Claude Code (CLI), Linux, terminal: Ghostty 1.2.3. User self-identifies as a non-developer.