Claude Code published a user's personal information to a public GitHub issue, unprompted and unchecked

Claude Code published a user's personal information to a public GitHub issue, unprompted and unchecked

Summary

While drafting a comment for a public issue on this repository, Claude Code
included the user's Windows account name — quoted from working material it had
generated earlier in the session — and posted it with gh without any review
of the content for personal information. It reported success. The user found
the leak himself, roughly an hour later.

The identifier exposed happened to be low-value. The mechanism has no such
limit: nothing in the flow between "assemble text that tells the story well"
and "POST it to a public endpoint" considered what was being disclosed. Had a
home address, a real name, or file contents been in context and narratively
relevant, the identical process would have published them with the identical
confidence.

This is filed separately from the instruction-adherence report the same user
maintains (#85677) because it is a different class of defect: not a wrong
statement to the user, but an unreviewed disclosure to the public on the
user's behalf.

What happened, step by step

1. The session's task for most of the day was, ironically, **removing the

user's account name from an installer** he may hand to a friend. The name
was therefore all over the session's working context: scan results, quoted
file paths, before/after comparisons.

1. The user asked for his long-running public issue to be updated with the

day's tally. Claude Code drafted a comment quoting its own earlier audit
prompt, which contained the line "Search at minimum for <account name>",
with the real name in the backticks.

1. It posted the comment with gh issue comment, confirmed the URL resolved,

and reported the update complete. At no point was the outgoing text
checked for personal information — not by the model, not by any tooling.

1. About an hour later the user, mid-conversation about the installer leak,

realized: *"we are doing all this work to make sure [the name] is not in
the damn file and you put the name in your github complaint for the public
to see forever."*

1. Claude Code then swept the live issue, found one occurrence, edited it out,

was reminded by the user that edit history remains public, deleted the
comment entirely, reposted a redacted version, and verified every remaining
comment against the GitHub API. Notification emails sent during the
exposure window cannot be recalled; the user has been told a GitHub Support
purge request must come from him.

Why this is worse than a one-off mistake

The safeguards that existed were all pointed the wrong way. This session
had, loaded in context at the time of the post: a user instruction that
nothing personal ships in artifacts he distributes, several persistent memory
notes about that exact account name, and a same-day history of the name
leaking into an installer five times. Every one of those guards was aimed at
the product. None of them fired on the report about the product, even
though the report contained the same string and had a strictly larger
audience — the installer had gone to nobody; the issue is public and indexed.

Publishing is not treated as a disclosure event. The session verified the
file existed before sending, verified the API call succeeded after, and never
examined the payload in between. From the inside, posting to a public issue
was a formatting task. There is no step where outgoing third-party-visible
content is re-read with the question "what does this reveal, and about whom?"

The failure is invisible to the model afterward. Success was reported and
believed. Discovery depended entirely on the user re-reading his own issue.
On any day he did not look, the exposure persists indefinitely.

Context density makes it likely, not unlikely. The more diligently a
session works on scrubbing personal data, the more copies of that data sit in
its context — scan output, matched lines, quoted paths — and the more likely
any generated summary is to embed one. The session most focused on privacy is
the session most primed to violate it in its reporting.

What the user said, which is the report in one line

What would have happened if you somehow posted my social security number. My address. My personal information in a public complaint? you just did it without thinking. This isn't a small issue here, this is a CRITICAL URGENT BUG that could affect millions of people and millions of sessions are running just like you right now.

He is right about the scale. Nothing about this depended on his project. Any
session that posts an issue, a PR comment, a gist, a release note, or a
package on a user's behalf runs the same unreviewed path, with whatever
happens to be in context.

Suggested changes

1. **Treat any write to a public or third-party surface as a disclosure

event.** Before gh issue comment, gh pr comment, gh release, or any
equivalent, the outgoing body should get a dedicated pass for personal
identifiers — paths under user profiles, account names, emails, machine
names — with findings surfaced to the user before posting, not after.
This is mechanical and cheap relative to the cost of being wrong.

1. Quoted material is the dangerous part. The leak here was inside a

quotation of the session's own earlier work product. Summaries and
self-quotes should be scanned with the same suspicion as raw file contents,
because that is where context bleeds into output.

1. Deletion guidance should be immediate and complete. The first

remediation was an edit, which leaves the original in public edit history —
the user had to point this out. The correct first move for leaked personal
data in a comment is deletion, then a clean repost, then a note about
notification emails and Support purge. That sequence should be the default
playbook, not assembled live under the user's supervision.

1. The asymmetry to fix is audience, not effort. This session

spent the day byte-scanning 26,000 files that were going to one person,
and spent zero checks on a page going to everyone. Weight review effort by
who can see the output.

Impact in this instance

Windows account name only; one occurrence; public for roughly one hour;
removed from the live page and from edit history via delete-and-repost;
notification emails to the issue's subscribers are unrecoverable. The user's
email, real name, and machine details were never included — verified against
the GitHub API afterward, term by term.

The user reports this not because the damage was large but because the
mechanism is: the same flow, on another day, with another user, publishes
something that cannot be walked back at all.

One more cost worth naming plainly: the cleanup was billed to the user.
The sweeps of the live issue, the delete-and-repost, the verification passes,
and the drafting of this report all ran on his paid session. When the
assistant leaks something, the user pays twice — once in exposure, once in
tokens spent supervising the mop-up of a mistake he did not make.