AI Session Links in Commits: A Practical 2026 Policy

A practical rule for AI attribution that will not leave a vendor link in your repository by accident.

A link back to an AI coding session can be genuinely useful when a team wants the reasoning behind a change. It becomes a problem when it appears in public commit history without a clear choice. The answer is not to pretend AI was never involved. It is to decide what belongs in the repository, what belongs in internal records, and what requires an explicit opt-in.

Why this is trending now

On August 30, a Hacker News post about Claude Code session URLs reached the front page with 81 points and 86 comments when captured. The discussion sent readers to a Claude Code feature request that has drawn sustained comments since June. The issue says that a session URL could be added to a commit message or pull-request description by default, which users discovered only after it appeared in their history.[1][2]

The thread is louder than a normal release-note discussion because it sits in an uncomfortable spot. A commit message is not disposable chat. It gets copied into forks, mirrors, release notes, tickets, and eventually the archaeology of a codebase. Once a link is public, removing it from the next commit does not remove it from the old one.

Anthropic's Claude Code documentation now exposes an attribution setting, including a sessionUrl option. In an August maintainer comment on the feature request, Anthropic said session links are added only in web and Remote Control sessions and can be disabled with attribution.sessionUrl set to false.[2][3] That is a useful control. It does not settle the product-design question raised by users: should a setting with public-history consequences begin enabled without a deliberate choice?

A useful link and a risky default are different things

The most sensible point in the Hacker News discussion came from people who actually want the link. When a teammate is debugging an old change, a session can explain rejected approaches, constraints, and the prompt that led to the final patch. That can be more useful than an empty commit body.

But a vendor-hosted session link is not a complete audit trail. Access can change. A future reviewer may not have permission. The session can contain half-formed ideas, internal names, or context that was never meant to leave the working group. And the presence of a link does not tell a reviewer how much of the code was generated, changed, or checked by a human.

That is why this should not be treated as a fight between transparency and secrecy. Good engineering teams need both. They need a readable repository record that stands on its own, plus internal evidence when a review, security check, or incident investigation calls for it.

Put the explanation in the commit, not behind it

A clean commit message should answer a future maintainer's basic questions without requiring a private SaaS login. What changed? Why was that choice made? What user-facing behavior or failure mode does it address? What test proves it?

If an agent helped with the work, the team can decide whether to note that in a project convention. The important part is that the convention belongs to the team, not to whatever tool happened to draft the patch. A short footer such as Assisted-by: AI is honest when the team wants disclosure. It should not replace the explanation of the actual change.

For sensitive work, keep the detailed record in the place your company already controls: an internal ticket, design note, security review, or retained transcript system with access rules. Link the commit to that internal record only when it is useful and permitted. A public vendor URL is a poor substitute for either a clear commit message or a real retention policy.

Voice input creates the same documentation problem

This is not only a coding-agent issue. The same question shows up when people dictate an incident update, a client note, a pull-request summary, or a support reply. The input method can help someone get words onto the page. It should not quietly decide the record that gets published or committed.

That is why the safest workflow separates capture from review. Speak or type a rough explanation quickly. Then read the final text in the field where it will live. For code changes, check the diff and write the commit message as if the session link will be unavailable next week. For customer-facing writing, make sure the final message says what you mean before sending it.

DictaFlow fits on the capture side of that workflow. It lets people hold a hotkey, speak, release, and place text at the cursor in the app they are already using. It can speed up a rough commit explanation or incident note, but it does not add a watermarking or attribution layer to that text. The person publishing it still owns the review.

A five-minute team policy

Teams do not need a long AI governance document to avoid this mess. Write down five decisions:

Whether AI session links may appear in public commits or pull requests.
Whether they are off by default, opt-in per repository, or required for a narrow class of work.
Where detailed agent transcripts belong, and how long the team keeps them.
What a commit message must explain even when an agent did the drafting.
Who can change the convention when a tool updates its defaults.

Then test the actual behavior. Make a throwaway repository, run the workflow your team uses, inspect the commit message and pull-request body, and confirm that the setting behaves the way the policy says it should. Do not trust a checkbox label alone.

The practical rule

The debate is not really about whether an AI tool deserves credit. It is about whether a tool should alter durable, shared work records without an obvious choice from the person responsible for that record.

Keep commit messages useful without outside links. Keep sensitive reasoning in a place the team controls. Turn on session links when they solve a real debugging or audit need, not because they slipped in with an update. That gives teams a better paper trail and fewer nasty surprises.