Skip to content

[cc] machine-parseable error code prefixes (ENOPEER, EAMBIGUOUS, EEXFIL) #85

@anipotts

Description

@anipotts

Source: Apr 2026 conventions audit

Problem

cc error responses are pure prose: `"cc.send: '' is ambiguous (multiple live sessions match)..."`. A caller (the model, or a test, or an automation) can't reliably distinguish "no peer" from "ambiguous peer" from "exfil refusal" without string-parsing.

The Anthropic SDK convention for tool errors is to include a stable `code` token early in the message so callers can match against it.

Fix

Standardize error format: `cc.: : `. Codes:

  • `ENOPEER` — no peer matches the `to` argument
  • `EAMBIGUOUS` — multiple peers match (need longer id)
  • `EEXFIL` — outbound payload references CC_DIR
  • `ENOSESSION` — `MY_SESSION_ID` not set
  • `EBADACTION` — discriminator rejected (zod errors)
  • `EBADARGS` — zod field validation failed

Implementation

Define a `CCError` enum + helper:

```ts
const CC_CODES = {
NO_PEER: "ENOPEER",
AMBIGUOUS: "EAMBIGUOUS",
EXFIL: "EEXFIL",
NO_SESSION: "ENOSESSION",
BAD_ACTION: "EBADACTION",
BAD_ARGS: "EBADARGS",
} as const;

function ccError(action: string, code: keyof typeof CC_CODES, msg: string) {
return errorText(`cc.${action}: ${CC_CODES[code]}: ${msg}`);
}
```

Update every `return errorText(`cc.: ...`)` site to use `ccError`.

Acceptance criteria

  • Every error returned by cc has the format `cc.: : `
  • Codes documented in README
  • Tests assert on code, not message text

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or requestpluginsPlugin code or plugin guide

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions