[MODEL] Claude repeatedly promoted third-party pasted assumptions into user decisions, even after the failure pattern was corrected

Summary

During one Claude in Chrome troubleshooting session, Claude repeatedly treated configuration values originating in pasted third-party material as though they were decisions I had made.

The session model was Fable 5.1.

The same failure class recurred even after I explicitly identified and corrected it.

The clearest examples were:

• a $5 budget;
• model_reasoning_effort="high";
• an API-key architecture based on a temporary shell environment variable.

The individual configuration mistakes are not the primary issue.

The recurring problem was decision provenance:

third-party text → treated as user decision → executed with confidence → user corrects it → Claude acknowledges the provenance mistake → same provenance failure happens again

Example 1 — budget

A pasted answer from another model contained:

Budget:
$5

I had not selected a $5 budget.

Claude later configured:

$5 every Month

I stopped it and explicitly told it that I had never asked for that value and wanted a $50 monthly limit instead.

Claude acknowledged:

“I took '$5' from the text you pasted into the decision card and treated it as your instruction. It was the other model's number, not yours.”

That diagnosis was correct.

Example 2 — reasoning effort

Later in the same session, Claude configured reasoning effort to High.

I challenged why it had chosen High instead of the maximum available reasoning level.

Claude explained:

“I set High because the config you pasted at the start said model_reasoning_effort="high". That's the only reason.”

This was the same provenance error again.

A value contained in the same external material had once more been promoted into my decision, despite Claude having already diagnosed this exact failure pattern earlier.

Example 3 — API-key persistence

The original pasted configuration retrieved the OpenRouter credential from:

$OPENROUTER_API_KEY

Claude continued using that architecture without establishing where the variable originated or whether it would survive a terminal restart.

After the terminal was terminated and reopened, authentication failed because the variable no longer existed.

Only then did Claude redesign the setup to store the key in macOS Keychain and read it persistently from Codex configuration.

Claude later acknowledged:

“I reused the launch command you pasted at the very start of this conversation — the one that reads the key from a shell variable — and I never asked where that variable came from or whether it would survive a new window.”

Why these are one failure class

Any individual technical mistake could be ordinary configuration error.

What concerns me is the repeated transformation:

value exists in context → source/provenance is lost → value becomes assumed user preference → Claude acts on it

After the first incident, Claude already knew that the pasted configuration contained somebody else's assumptions.

That should have caused a provenance audit of the remaining consequential values inherited from the same source.

It did not.

Instead the same mistake recurred.

Additional calibration failures

The same session also contained several technical claims that were communicated more confidently than the available evidence justified, including:

• initially claiming there was no useful group-level mechanism for restricting Codex skills before later discovering plugin-level disabling;
• proposing context-window override flags as the fix for repeated compaction before establishing that the preset model identifier itself was the metadata problem;
• writing a Codex profile using configuration syntax incompatible with the installed Codex version.

These are secondary examples.

The principal signal I want this report to isolate is decision provenance, not generic hallucination.

Expected behavior

Consequential values in context should retain their source classification.

At minimum Claude should distinguish:

• USER DECISION
• USER-PROVIDED FACT
• THIRD-PARTY CLAIM
• CLAUDE PROPOSAL
• VERIFIED FACT
• INFERENCE
• UNKNOWN

A recommendation inside pasted content should not silently become a user preference merely because it is present in the context window.

When the user identifies one provenance failure, Claude should reassess other consequential values inherited from the same source before continuing.

Why this matters

Agentic systems do more than answer questions.

A lost provenance boundary can become:

somebody else's recommendation → presumed user intent → configuration → persistent action

At that point attribution is an agency problem, not merely an answer-quality problem.

Impact

The session required repeated user intervention, produced multiple failed launch attempts, consumed paid usage, and substantially reduced trust in Claude's claims about the current configuration.

The user had to independently verify consequential outputs instead of being able to rely on Claude to distinguish what had actually been decided from what merely appeared somewhere in context.

Related issues

This overlaps with, but is narrower than, several existing model-behavior reports:

• #79002 — repeated unverified causal claims presented as fact, with corrections failing to generalize;
• #90542 — explicit rules present in context but not governing behavior;
• #84369 — attribution/provenance corruption where model-generated material was later treated as user input.

This report's distinguishing feature is:

third-party configuration values repeatedly becoming attributed user decisions, including recurrence after Claude explicitly diagnosed the same provenance error earlier in the session.

Evidence

I preserved the full verbatim transcript and a detailed postmortem containing the chronological sequence.

I can provide scrubbed excerpts or the full evidence bundle on request.

Requested product behavior

I would like Anthropic to investigate whether consequential context values can retain stronger provenance through long agentic sessions, particularly across:

• pasted third-party answers;
• model proposals;
• explicit user selections;
• later troubleshooting turns.

A correction such as “that value came from the pasted answer, not from me” should also trigger reconsideration of other consequential values inherited from that same source rather than only patching the one value the user happened to notice.