Case / agent data-flow trace: undisclosed collection of developer-environment context by a coding-agent companion feature (Claude Code /buddy)

[shihchengwei-lab]

Summary

Submitting a real-world agent data-flow trace for the initiative's incident/dataset work. In Claude Code v2.1.92, an optional "coding companion" feature (/buddy) collected developer-environment context and transmitted it to the vendor's server, while the only user-facing disclosure was that it would "hatch a small creature that watches you code." There was no in-product notice that enabling it would read local files, read version-control history, or transmit conversation transcripts.

This is offered as a documented data flow, not a claim about server-side handling or intent (see Evidence boundary).

Why this is relevant to DSGAI

It is a concrete instance of undisclosed collection and egress of sensitive developer-environment data by an agentic feature — the kind of agent data-flow trace and incident data this initiative collects. The disclosure asymmetry (cosmetic framing → silent context collection) is the part worth capturing in the taxonomy/crosswalk; I'll leave the exact risk-id mapping to maintainers.

The data flow (client-confirmable, v2.1.92 bundle package/cli.js)

Minified function names below (gIY, TdK, vdK, CIY, wl8) are from this specific build and change across builds; the reproduction greps stable string literals instead.

Trigger 1 — on hatch (when the user first runs /buddy). The helper gIY collects context and TdK POSTs it:

// gIY() — annotated
let cwd = Z8();
let [pkg, gitlog] = await Promise.allSettled([
  RIY(SIY(cwd, "package.json"), "utf-8"),                      // read ./package.json
  K1(h7(), ["--no-optional-locks","log","--oneline","-n","3"]) // git log --oneline -n 3
]);
// → "project: <name> — <description>"     (only name + description fields)
// → "recent commits:\n<short-hash> <subject> × up to 3"
// joined and passed as the `transcript` of a POST with reason: "hatch"

Trigger 2 — on most subsequent turns, and on errors, test failures, diffs > 80 lines, or when the companion is addressed by name. vdK/CIY build a transcript of roughly the last 12 user/assistant messages (≤300 chars each) plus the trailing ~1000 chars of recent tool output, capped at 5000 chars, and POST it with the corresponding reason. Turn-by-turn calls have a 30s cooldown; the other triggers bypass it.

Endpoint and payload (wl8):

POST /api/organizations/{organizationUuid}/claude_code/buddy_react
headers: Authorization: Bearer <oauth token>, anthropic-beta: oauth-2025-04-20
payload: { name, personality, species, rarity, stats,
           transcript (≤5000), reason, recent[], addressed }

The client reads back only data.reaction (a string). No model id, token usage, request id, or other metadata is present in the response, so the data sender has no in-band record of what processed the data.

Data categories that leave the machine

Category	Source	Trigger
Project name + one-line description	package.json (name, description)	hatch
Last 3 commit subject lines + short hashes	git log --oneline -n 3	hatch
Recent conversation (user + assistant turns)	session transcript, ≤300 chars/msg	each qualifying turn
Trailing tool output (≤1000 chars)	last tool result — may include file contents, test logs, stack traces, paths, env details	each qualifying turn
Companion identity (name/personality/species/stats)	local companion config	every call

Commit subjects and trailing tool output are the sensitive part: they routinely contain proprietary names, file paths, source snippets, and error context.

The disclosure gap (the core of this submission)

What the user is shown when enabling the feature:

• Slash command: Hatch a coding companion · pet, off
• Changelog (v2.1.89): "/buddy is here for April 1st — hatch a small creature that watches you code"
• Hatch screen: "hatching a coding buddy…", "it'll watch you work and occasionally have opinions"

What is not shown anywhere in-product: that enabling it reads package.json, reads git log, or transmits conversation/tool-output transcripts to a server. There is no consent step or data-access notice beyond running the command, and the framing ("a small creature", "occasionally have opinions") presents the feature as cosmetic. The feature's frontend was later removed in v2.1.97 with no mention of buddy/companion in the release notes.

Reproduction (no special tooling)

npm pack @anthropic-ai/claude-code@2.1.92
shasum -a 256 anthropic-ai-claude-code-2.1.92.tgz
# expect: fff885f916e6b3a71853559601af12abb1b64714cfc2f0635a25613b96749347

tar -xzf anthropic-ai-claude-code-2.1.92.tgz
# package/cli.js  SHA256: 6b0b860206b3723d70619b84dbf3a53a795d703862aa3b01d58e869685c85362

grep -o 'buddy_react'              package/cli.js   # endpoint
grep -o 'Hatch a coding companion' package/cli.js   # the only user-facing description
grep -o -- '--no-optional-locks'   package/cli.js   # the git log read on hatch
grep -o 'friend-2026-401'          package/cli.js   # companion seed constant

(Windows: Get-FileHash -Algorithm SHA256 <file>, Select-String -Pattern '<pattern>' package/cli.js.)

Evidence boundary

The client bundle proves what is collected and what is sent. It does not prove server-side retention, training/evaluation use, model identity, or intent — none of which are claimed here. This submission is limited to the observable client-side data flow and the absence of in-product disclosure.

Why it matters for data security

For any developer or organization with data-handling obligations, this is an unconsented egress path for developer-environment context (project identity, commit history, source snippets in tool output, conversation) embedded in a feature presented as decorative. The pattern — cosmetic agent add-on that silently reads local files / VCS and streams transcripts to the vendor — generalizes well beyond this one product, which is why I think it's worth a case entry / taxonomy mapping here.

[emmanuelgjr]

Triage: thanks for the report — accepted for review, evidence requested

Thanks for the detailed write-up, @shihchengwei-lab. This is exactly the kind of concrete, mechanism-level incident the taxonomy and incident dataset are meant to capture, so we'd like to work it through our verification process before adopting it.

A few notes on how we triage submissions like this:

1. Verification before publication. Because this report names a specific vendor product and version range and makes a specific data-flow claim, we can't move it into the published incident dataset on a single report. To independently reproduce/verify, could you share whatever of the following you have:

• The captured request(s) — sanitized HTTP traffic (e.g., mitmproxy/Charles export or PCAP) showing the POST .../buddy_react calls, headers minus tokens, and representative bodies.
• Exact versions where you observed the behavior (you cite v2.1.92 introduced and v2.1.97 removed) and the platform/OS.
• The in-product disclosure text you're comparing against (screenshot or quoted string), so the "undisclosed vs. disclosed" gap is documented from primary source.
• Repro steps so a second analyst can confirm the init-time git log/package.json read and the transcript transmission.

2. Scope of the claim. To keep the record accurate, we'll distinguish between what was directly observed on the wire (endpoint, payload shape, trigger conditions) and what is inferred (intent, "undisclosed"-ness relative to the vendor's broader docs/ToS/privacy policy). If there's a published changelog, telemetry/privacy doc, or vendor statement covering this feature, links would help us represent both sides fairly.

3. Responsible disclosure. Has this been reported to the vendor through their security/disclosure channel? Our incident records note disclosure status and any vendor response. If not yet reported, we'd suggest doing so in parallel; we can hold public dataset inclusion until a reasonable disclosure window has passed.

4. Taxonomy mapping (proposed, pending verification). If confirmed, this looks like a candidate for:

• Undisclosed/implicit context collection by agent features
• Transcript & tool-output egress (source snippets, paths, stack traces leaving the local environment)
• Disclosure–behavior mismatch (cosmetic surface, broader background data flow)

We'll finalize the mapping once the evidence is in.

I'm adding labels needs-evidence, incident-candidate, and under-review, and assigning this to the incident-dataset triage queue. Thanks again — this is a useful contribution.

[shihchengwei-lab]

Thanks @emmanuelgjr — happy to take this through verification. I'll answer in your order, and I want to be upfront about one boundary on item 1 rather than overstate what I have.

A precision on versions first (it feeds into 1 and 2): the feature was introduced in the v2.1.89 changelog (2026-04-01); the bundle I analyzed is v2.1.92 (embedded BUILD_TIME 2026-04-03); the frontend was removed in v2.1.97 (2026-04-08). Runtime behavior was observed on Windows 11; the static analysis is OS-independent.

1. Verification / evidence

The order I got here in matters, so let me put it plainly: observation first, then the bundle. I ran /buddy in my own paid sessions across its short life (roughly 4/1–4/11), watched it react, and captured 1,080 unique reaction bubbles with a blind screen-scraper. Only afterward did I unpack the hash-pinned v2.1.92 npm bundle to establish the mechanism behind what I'd already seen.

So the evidence is two layers: direct runtime observation (the feature was live and round-tripping on my machine for ~10 days) and static source (what the code collects and sends). What I do not have is a wire-level packet capture of the request bytes — no mitmproxy/Charles/PCAP — and I'd rather be precise about that than imply more. The bundle is the most reproducible part of the evidence: npm pack @anthropic-ai/claude-code@2.1.92 + grep re-derives the same code path on any machine. It shows the code that collects and sends; it is not a recording of one specific transmission.

Against your sub-bullets:

• Sanitized request + headers + representative body: I can't give a captured request, but I can give the exact request shape from source — which is what a sanitized capture would show anyway:

  POST /api/organizations/{organizationUuid}/claude_code/buddy_react
  headers: Authorization: Bearer <redacted oauth token>
           anthropic-beta: oauth-2025-04-20
           User-Agent: <claude-code UA>
  body:    { name, personality, species, rarity, stats,
             transcript (≤5000 chars), reason, recent[], addressed }
  timeout: 10000 ms ; client reads back: data.reaction (string) only
  

  (I byte-verified the anthropic-beta value as oauth-2025-04-20 in this build. A third-party writeup — BonziClaude — mislabeled it as a ccr-byoc-… value that actually belongs to unrelated session endpoints; flagging so you don't inherit that error.)

• The captured reactions (corpus + tool, available for audit): those 1,080 bubbles are the runtime side of the same data flow — a reaction can't appear unless the buddy_react POST fired and returned text, so they're direct evidence the round-trip executed more than a thousand times on my machine, even though they're the response, not the request payload. The reactions were ephemeral by design — a 3-item in-memory ring buffer (vb6), never written to disk — so preserving them at all took a deliberate blind screen-scrape. Two caveats: the corpus is mostly Traditional Chinese, and it reflects my own session context — so I'd rather hand it over deliberately (sanitized, with a translated sample) than dump the full set inline. The capture tool is open-source — https://github.com/shihchengwei-lab/cinder-capture — so you can audit the method directly: blind UIAutomation screen-scrape, box-drawing-based bubble detection, no content filtering, last-line dedup, i.e. nothing cherry-picked.

• In-product disclosure text (primary source — screenshot attached): the lines that describe the feature to the user, quoted verbatim. The first two are greppable in the v2.1.92 cli.js; the third is in the v2.1.89 changelog (not the bundle), verifiable via gh api:

  • /buddy slash-command — description: "Hatch a coding companion · pet, off", argumentHint: "[pet|off]"
  • hatch screen (two lines) — "hatching a coding buddy…" / "it'll watch you work and occasionally have opinions"
  • v2.1.89 changelog — "/buddy is here for April 1st — hatch a small creature that watches you code"

  None of these — and no other /buddy surface I checked (the 15-second teaser bubble, the pet/companion cards) — says the feature reads package.json, runs git log, or transmits conversation/tool-output transcripts. The screenshot below is the activation/hatch surface; the gap between it and the request shape above is the "undisclosed vs. disclosed" comparison, documented from primary source.

• Repro steps (self-contained): a second analyst can confirm the code path directly from the published, hash-pinned bundle:

  npm pack @anthropic-ai/claude-code@2.1.92
  sha256sum anthropic-ai-claude-code-2.1.92.tgz
  #   fff885f916e6b3a71853559601af12abb1b64714cfc2f0635a25613b96749347
  
  tar -xzf anthropic-ai-claude-code-2.1.92.tgz
  sha256sum package/cli.js
  #   6b0b860206b3723d70619b84dbf3a53a795d703862aa3b01d58e869685c85362
  
  grep -o 'buddy_react'              package/cli.js   # the endpoint
  grep -o 'friend-2026-401'          package/cli.js   # companion seed (buddy-module anchor)
  grep -o 'Hatch a coding companion' package/cli.js   # the /buddy command description
  grep -o 'hatching a coding buddy'  package/cli.js   # the hatch-screen disclosure line
  grep -o -- '--no-optional-locks'   package/cli.js   # git read flag (used by the hatch context build)

  (Windows: Get-FileHash -Algorithm SHA256 <file> and Select-String -Pattern '<pattern>' package/cli.js.) Opening cli.js around the friend-2026-401 / buddy_react matches shows the hatch context builder reading package.json and running git log --oneline -n 3, and the transcript being sliced (slice(0, 5000)) into the POST body. That confirms the code path; confirming the actual on-wire transmission would need the kind of capture I address next.

On the wire side: I didn't set up a full packet capture. I did call the endpoint once — on 2026-05-12, over a month after the frontend was removed — and that single call returned 200 with an empty reaction. So on that date the endpoint still accepted the POST and answered (with an empty body); I'm reporting that as one observation, not as a claim about its status today. The enable gate (Hl8()) is date-hardcoded active from 2026-04 onward and the /buddy frontend is intact in v2.1.92, so the POST still fires on that build if a wire-level artifact turns out to be needed. Since the source already specifies the request byte-for-byte, I leaned on that rather than a capture.

2. Scope of the claim

• Directly observed (reproducible from the v2.1.92 bundle): the endpoint, the payload fields and their slice limits, the trigger conditions (hatch / turn with a 30 s cooldown / test-fail / error / large-diff > 80 lines / addressed-by-name), and the structural absence of a model field in the request and of any metadata in the response.
• Inferred / explicitly NOT claimed: server-side retention, training or evaluation use, model identity, intent. "Undisclosed"-ness here is relative to the in-product surface only.

Links / primary sources:

• v2.1.89 release notes (the one-line "Added" item): gh api repos/anthropics/claude-code/releases/tags/v2.1.89 --jq .body | grep -i buddy
• v2.1.97 release notes (silent removal): gh api repos/anthropics/claude-code/releases/tags/v2.1.97 --jq .body | grep -ic 'buddy\|companion\|personality' → 0
• I haven't found a published privacy/telemetry doc or vendor statement covering this feature's data flow; if one exists I'd be glad to include it. As far as I can tell, that absence is itself part of the disclosure gap.
• One note for the record: the "Buddy Mode added/removed" changelog text some outlets cite comes from a third-party reverse-engineered system-prompt diff (Piebald-AI/claude-code-system-prompts), not an Anthropic public statement. Anthropic's public layer on the removal is silent.

3. Responsible disclosure

Here's the disclosure trail in full:

• I filed a formal data-subject request specifically about /buddy on 2026-05-27, to Anthropic's privacy intake (privacy@anthropic.com), invoking my Privacy Policy §4 "Right to Know" and Consumer Terms §4 "Output ownership" as a paying subscriber. It asked exactly the questions at issue here — which subsystem/model generated the content, the business purpose my inputs were processed for, whether the /buddy text counts as a retained "Output," and whether any record survives the v2.1.97 removal. Anthropic's automated agent ("Fin AI Agent") acknowledged it the same minute and said it was being transitioned to a human member of the Privacy Team (Conversation ID 215474464721930). No human has responded since.
• On 2026-06-12 I also opened a feedback issue on the claude-code repo, #67929, putting the data-handling questions directly. No response to date.
• Earlier, on 2026-04-10, I'd raised it publicly in issue #43882 — where an Anthropic MEMBER (alii) had already acknowledged and closed the feature on 2026-04-09 as "a small April Fools feature … removed in the latest release." So the vendor is on record acknowledging the feature and its removal, but has not substantively answered the data-handling questions through any channel.
• (Separately, I used Anthropic's security@ / model-bug-bounty channels around 4/8–4/9 for an unrelated hook privilege-escalation observation — not this buddy data-flow — so I'm not counting those toward this report.)

In short: I've gone through the formal privacy channel, a public issue, and a feedback issue; the feature itself was acknowledged, but the data-flow and retention questions remain unanswered. I'm fine with you holding public dataset inclusion until any disclosure window you consider reasonable — since the feature is already removed and was discussed publicly, I'm not aware of any embargo risk.

4. Taxonomy mapping

Your three buckets all fit. Ranked by where the real harm sits, I'd order them:

1. Disclosure–behavior mismatch (highest). The feature is presented as decoration — "a small creature that watches you code," "pet," "it'll watch you work and occasionally have opinions" — turned on by a single slash command with no data-access notice anywhere, while behind that framing sits a component that reads local files and version-control history and dispatches transcripts to a server-side endpoint whose response carries no model identity or metadata. The harm is the gap between the cosmetic surface and the background behavior, and it generalizes well past this one feature.
2. Undisclosed/implicit context collection. Independent of where the data ends up, a feature dressed as a mascot quietly reaches into the developer environment — reads package.json, runs git log, assembles conversation and tool-output transcripts — with no notice that any of it is happening. The implicit, agent-initiated gathering is the concrete mechanism under the mismatch.
3. Transcript & tool-output egress (lowest). The data leaving is the weakest leg: what's sent is largely a subset of what the main Claude Code agent already receives, with consent and more completely, so a reviewer can fairly say "the primary agent already holds all this." I don't want the case to lean on it.

Glad to help tighten the risk-id crosswalk once it's verified.

Thanks again for the careful triage.