You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
createPmCliExpectedError(message, { context }) and new PmCliError(message, exitCode, context) take PmCliErrorContext, which is a closed interface. It lists only host fields: code, value, required, why, verification_errors, policy_violations, lease, recovery and so on. An extension can't attach its own structured diagnostics to a typed refusal, so agents get those diagnostics only as prose in message.
Real case
pm-changelog refuses a release whose requested version has no changelog section (unbraind/pm-changelog#302). The standalone CLI returns a selection_report object (filters, stage counts, excluded counts) in its JSON error. That's what an agent needs to decide whether to close items, set release, or pass --include-empty. The same refusal through the extension command (pm changelog generate) can't carry that object:
thrownewPmCliError(msg,EXIT_CODE.GENERIC_FAILURE,{code: error.code,version: error.version,report: error.report});// TS2353: Object literal may only specify known properties, and 'version' does not exist in type 'PmCliErrorContext'.
The workaround spreads the facts over unrelated fields: value for the version, required for the remedy, and verification_errors: ["excluded_status=1", ...] for the counts. That works, but the field names don't match their meaning, and nested structure is lost.
Proposal
Add one namespaced, JSON-serializable slot for extension diagnostics, for example:
The host would render it in --json/TOON error output and apply its usual size budget and redaction. Telemetry and Sentry should ignore it, so extension payloads can't leak user data into crash reports.
Why
pm's goal is context management for agents. A typed refusal is most useful when its machine-readable facts reach the agent. Today only the host's own refusals can do that.
Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.
Create Plan
🧪 Issue enrichment is currently in open beta.
You can configure auto-planning by selecting labels in the issue_enrichment configuration.
To disable automatic issue enrichment, add the following to your .coderabbit.yaml:
issue_enrichment:
auto_enrich:
enabled: false
💬 Have feedback or questions? Drop into our discord!
A bounded, namespaced SDK refusal-diagnostics field with CLI/TOON/JSON support and explicit telemetry/Sentry exclusion. The item is open and unclaimed, with duplicate-check, planning and relationship evidence recorded.
Activity
coderabbitai commentedon Oct 29, 2026
🔗 Related PRs
#1586 - fix(sdk): expose mutation completion and refusal audit provenance [merged]
📝 Issue Planner
Check the box below or use the
@coderabbitai plancommand to generate an implementation plan and prompts that you can use with your favorite coding assistant.🧪 Issue enrichment is currently in open beta.
You can configure auto-planning by selecting labels in the issue_enrichment configuration.
To disable automatic issue enrichment, add the following to your
.coderabbit.yaml:💬 Have feedback or questions? Drop into our discord!
fix(sdk): validate serialized output and contain extension fault data
unbraind commentedon Oct 30, 2026
Tracked in pm-gh1631.
A bounded, namespaced SDK refusal-diagnostics field with CLI/TOON/JSON support and explicit telemetry/Sentry exclusion. The item is open and unclaimed, with duplicate-check, planning and relationship evidence recorded.
fix(refusals): address the first Codex review round on PR #1649
fix(refusals): address the second Codex review round on PR #1649