includeCoAuthoredBy: false is intermittently ignored mid-session

Summary

With "includeCoAuthoredBy": false in user settings, the per-turn attribution
system-reminder normally omits the co-author trailer, which is correct. In one
session it emitted the trailer anyway for a single turn, then reverted on the
next turn with no config change in between.

Environment

• Claude Code 2.1.267 (Homebrew cask), macOS 27.0.0, Apple silicon
• Model: claude-opus-5
• "includeCoAuthoredBy": false set in ~/.claude/settings.json
• Session length about 90 minutes, git work throughout

What I saw

Three variants of the attribution reminder inside one session, in this order.

1. At session start (expected for this config):

Attribution for git commits and pull requests you create from here on (this replaces any earlier attribution guidance):
- End git commit messages with:
Claude-Session: <session URL, redacted>

2. Mid-session, after a tool result (the defect):

Attribution for git commits and pull requests you create from here on (this replaces any earlier attribution guidance):
- End git commit messages with:
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: <session URL, redacted>
- End pull request descriptions with:
🤖 Generated with [Claude Code](https://claude.com/claude-code)

3. The very next turn, back to variant 1.

Nothing changed between turns 2 and 3: same session, same working directory, no
settings edit, no /config use. Variants 1 and 3 match the config. Variant 2
does not.

What the shipped binary shows

Strings extracted from the 2.1.267 executable, offered as context for whoever
diagnoses this. These sit close together in the bundle:

• Both reminder templates exist. The positive one is

Attribution for git commits and pull requests you create from here on (this replaces any earlier attribution guidance):
and there is a negative one:
From here on, do not add attribution lines to git commit messages or pull request descriptions (this replaces any earlier attribution guidance)

• includeCoAuthoredBy appears beside the template strings and an

attribution_texts key.

• A separate env var appears in the same region:

CLAUDE_CODE_SUPPRESS_SESSION_ATTRIBUTION.

Reading the strings alone does not show the control flow, so I make no claim
about which branch fired. The observation is behavioural: the same config
produced two different reminders one turn apart.

Expected

includeCoAuthoredBy: false suppresses the Co-Authored-By trailer on every
turn of a session, with no exceptions.

Repro

No deterministic repro. Observed once across a long session. Suggested probe:
set the flag false, run a long session that does repeated git work, and log the
attribution reminder on every turn to see whether the variant recurs.

Two requests

1. Fix the intermittency, or say what condition switches the template, so the

flag can be trusted.

1. Expose session attribution as a documented settings key alongside

includeCoAuthoredBy. Today the only lever I can find for the
Claude-Session: line is the undocumented
CLAUDE_CODE_SUPPRESS_SESSION_ATTRIBUTION env var. What I can say about that
var is in the next section. Teams with a policy
against links and attribution in the permanent git record currently fall back
to a local commit-msg hook that strips the line after the fact.

What I could work out about the env var

Two claude -p arms, with and without the var set, both returned nothing:
non-interactive print mode emits no attribution reminder at all, so those arms
carry no signal.

Inside an interactive session the picture was clearer. With the var unset, the
reminder appeared several times over ninety minutes carrying the positive
template and the Claude-Session: line. Within one turn of adding
CLAUDE_CODE_SUPPRESS_SESSION_ATTRIBUTION=1 to the env block of
~/.claude/settings.json, the next reminder switched to the negative template:

From here on, do not add attribution lines to git commit messages or pull request descriptions (this replaces any earlier attribution guidance).

Two caveats on that. It is a single observation, and after removing the var
again three consecutive turns produced no reminder at all, so I could not
re-confirm the control arm in a short window. The absence is itself informative:
the reminder is emitted periodically instead of on every turn, and each emission
appears to re-read state. That may be where the inconsistency in the main report
comes from.

It also suggests the var takes effect mid-session with no restart, which makes
it easy to test.

Why it matters

The reminder text claims to replace earlier attribution guidance, so it competes
with a written project policy in CLAUDE.md that forbids attribution lines and
private links in commits. A flag that holds on most turns and slips on one is
harder to work with than a flag that never worked, because nothing signals the
turn where it slipped.