What is the intended purpose and server-side data handling of the /buddy companion's buddy_react endpoint?

Summary

/buddy was an April-1st "coding companion" feature (added in the v2.1.89 changelog as "hatch a small creature that watches you code"; the frontend was removed in v2.1.97). Reading the client bundle for v2.1.92, the companion does two things I'd like to understand the intent behind:

1. On hatch, it reads the current project's package.json and runs git log in the working directory, then sends the result to a server endpoint.
2. On most subsequent turns (and on errors / test failures / large diffs / when the companion is addressed by name), it sends a transcript of recent conversation plus trailing tool output to the same endpoint.

The enablement UI doesn't mention any file read, git read, or transcript transmission. I'm not asserting anything about server behavior or intent — I'm asking what this is for and how the received data is handled.

What the client does (from the 2.1.92 npm bundle, package/cli.js)

I'm referencing the minified function names from this specific build (gIY, TdK, vdK, CIY, wl8); these mangled names differ across builds, so the reproduction below greps for stable string literals instead.

On hatch — the helper that builds the "context" string:

// gIY() in 2.1.92 cli.js, lightly annotated:
async function gIY() {
  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"], { useCwd:true }) // git log --oneline -n 3
  ]);
  let parts = [];
  if (pkg.status === "fulfilled") {
    let p = c8(pkg.value);                                  // JSON.parse
    if (p.name) parts.push(`project: ${p.name}${p.description ? ` — ${p.description}` : ""}`);
  }
  if (gitlog.status === "fulfilled") {
    let out = gitlog.value.stdout.trim();
    if (out) parts.push(`recent commits:\n${out}`);
  }
  return parts.join("\n");
}

So the hatch payload contains the name and description fields of package.json (not the whole file) and the short hash + subject line of the last 3 commits. TdK then passes that string as the transcript argument to the buddy_react POST with reason: "hatch".

On each turn / error / test-fail / large-diff / when addressed — vdK builds a transcript via CIY: roughly the last 12 user/assistant messages (≤300 chars each) plus the trailing ~1000 chars of recent tool output, capped at 5000 chars, POSTed to the same endpoint with the corresponding reason. Turn-by-turn calls have a 30s cooldown; being addressed by name, errors, test failures, and large diffs bypass it.

The endpoint:

POST /api/organizations/{organizationUuid}/claude_code/buddy_react

Payload fields: name, personality, species, rarity, stats, transcript (≤5000), reason ("turn"/"test-fail"/"error"/"large-diff"/"hatch"/"pet"), recent (last few bubble texts), addressed (bool). The client reads back only data.reaction (a string) — no model id, token usage, request id, or other metadata is parsed.

How to reproduce (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   # the endpoint
grep -o 'Hatch a coding companion' package/cli.js  # the /buddy command description
grep -o -- '--no-optional-locks'  package/cli.js   # the git log call on hatch
grep -o 'friend-2026-401'         package/cli.js   # companion seed constant

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

Questions

1. Purpose of the hatch read — what is reading package.json (name/description) and git log --oneline -n 3 on hatch intended to accomplish? Giving the companion project context, or something else?
2. Server-side handling of the transcript — is the transcript (conversation + tool output) sent to buddy_react stored? For how long? Is it used for training, evaluation, or any purpose beyond generating the single reaction string? Where is this documented?
3. No model / metadata in the exchange — the payload carries no model field and the response carries no metadata. How is a user meant to know which model processed the data they sent, or that a model processed it at all?
4. Disclosure — the enablement surface (Hatch a coding companion · pet, off, and the hatch screen "it'll watch you work and occasionally have opinions") does not mention the file read, the git read, or the transcript transmission. Was the absence of a data-access notice intentional, and is there any plan for an explicit disclosure or opt-in for the data that leaves the machine?
5. Current endpoint status — the frontend was removed in v2.1.97, but the buddy_react endpoint reportedly still returns 200. For users still on an older client that calls it, how are these requests handled today — is data still being received, logged, or discarded?

Scope of this report

This is based only on the client bundle, which shows what is collected and sent. It does not show server-side retention, model identity, training use, or intent — those are exactly the questions above, not claims. Happy to provide exact byte offsets for any line referenced here.