Skip to main content

AxonFlow v7.4.3 Release Notes

AxonFlow v7.4.3 is a documentation-grade patch. Two MCP-response schemas have been stale relative to what the agent has emitted since the Plugin Batch 1 work in v7.1.0. AxonFlow's hand-written plugins (OpenClaw, Claude Code, Cursor, Codex) all read these fields correctly because they were authored against actual server responses; the OpenAPI spec just hadn't been updated. Code-generated clients written against the prior spec would have read undefined for these fields.

Same day, the four AxonFlow SDKs caught up to the same field set as a coordinated cycle: TypeScript v6.1.0, Python v6.8.0, Go v5.8.0, and Java v6.1.0.

SurfaceVersionChange type
Platformv7.4.3PATCH — MCP-response spec corrections
TypeScript SDKv6.1.0MINOR — additive Plugin Batch 1 fields
Python SDKv6.8.0MINOR — additive Plugin Batch 1 fields
Go SDKv5.8.0MINOR — additive Plugin Batch 1 fields
Java SDKv6.1.0MINOR — same field set

MCPCheckInputResponse gains 5 fields​

The agent has emitted these on /api/v1/mcp/check-input since v7.1.0 (Plugin Batch 1 richer block context); the spec just hadn't documented them.

  • decision_id — audit correlator linking this MCP decision to its audit_logs row.
  • risk_level — one of low, medium, high, critical. Drives client-side approval UX (e.g. plugins that route high/critical to a HITL queue).
  • policy_matches — array of ExplainPolicy records (per-policy explainability). Each entry carries policy_id, policy_name, action, risk_level, allow_override, policy_description.
  • override_available — boolean. True if the matched policies allow a session override (governed via POST /api/v1/policies/{id}/overrides).
  • override_existing_id — string. If a session override is already active and was consumed by this decision, the override's UUID is returned here.

MCPCheckOutputResponse gains 3 fields​

Same Plugin Batch 1 surface, output side.

  • decision_id
  • policy_matches — array of ExplainPolicy
  • redacted_message — text-redaction counterpart to redacted_data. Used when the connector returned a string message (e.g. an execute-style response) rather than tabular rows.

New explainability schemas​

Three schemas added to agent-api.yaml to describe the explainability surface returned by client.explainDecision() and the explain_decision MCP tool:

  • ExplainPolicy — per-policy explainability record. Same shape used in policy_matches arrays above.
  • ExplainRule — per-rule explainability record (one rung lower than policy: a single regex / condition fired within a policy).
  • DecisionExplanation — full payload returned by GET /api/v1/decisions/{id}/explain and the explain_decision MCP tool.

The matching documentation page at Governance / Explainability already documented the field shape; v7.4.3 adds the OpenAPI artefact. See also MCP Policy Enforcement for the MCP-side surface.

SDK catch-up — TypeScript v6.1.0, Python v6.8.0, Go v5.8.0, Java v6.1.0​

All four SDKs surface the same field set on the same day. Pure Cat B field-additions on existing methods — no new SDK methods, no breaking changes. Pre-v7.1.0 platforms return zero/null/undefined for every field; callers should treat absence as "context not available" rather than an error.

TypeScript v6.1.0​

  • MCPCheckInputResponse gains decision_id?, risk_level?, policy_matches?: MCPExplainPolicy[], override_available?, override_existing_id?.
  • MCPCheckOutputResponse gains decision_id?, policy_matches?, redacted_message?.
  • New exported interface MCPExplainPolicy — snake_case wire shape. Distinct from the existing camelCase ExplainPolicy (in src/types/decisions.ts), which is the hand-decoded view returned by client.explainDecision(). Both describe the same logical record; the dual-name distinction follows the SDK's existing wire-vs-decoded convention.

Python v6.8.0​

  • MCPCheckInputResponse gains decision_id, risk_level, policy_matches: list[ExplainPolicy] | None, override_available, override_existing_id.
  • MCPCheckOutputResponse gains decision_id, policy_matches, redacted_message.
  • ExplainPolicy is now re-exported from axonflow.types (was previously only in axonflow.decisions). Same Pydantic model — Python's snake_case convention naturally aligns wire-shape and SDK types, so no separate model is needed.

Go v5.8.0​

  • MCPCheckInputResponse gains DecisionID, RiskLevel, PolicyMatches []ExplainPolicy, OverrideAvailable *bool, OverrideExistingID.
  • MCPCheckOutputResponse gains DecisionID, PolicyMatches, RedactedMessage.
  • ExplainPolicy already shipped (in decisions.go) — same struct now reused on MCP responses.

Java v6.1.0​

  • Same field set on MCPCheckInputResponse / MCPCheckOutputResponse. ExplainPolicy already shipped on the decisions side — same Jackson-annotated record reused on MCP responses.

Deferred across all four SDKs​

client.explainDecision(decisionId) and the full ExplainRule / DecisionExplanation shapes (returned by the explain_decision MCP tool) are tracked separately as feature work — see axonflow-enterprise#1716. v7.4.3 / v6.1.0-train ships only the field-surfacing on existing methods.

Companion plugin gate work​

The four AxonFlow plugins (OpenClaw, Claude Code, Cursor, Codex) have wire-shape contract gates that mirror the four SDK gates. Each gate's initial baseline grandfathers Plugin Batch 1 fields as known spec-missing drift; the next baseline regen against this v7.4.3 spec auto-resolves the bulk:

  • OpenClaw plugin: 7 SDK-only fields cleared from MCPCheck* responses + 3 unmapped types (ExplainPolicy / ExplainRule / DecisionExplanation) now mapped.
  • Claude Code / Cursor / Codex plugins: 5 plugin-only field entries clear per plugin (4 from MCPCheckInputResponse + 1 from MCPCheckOutputResponse).

SDK and plugin compatibility​

SurfaceVersion
Python SDKv6.8.0
Go SDKv5.8.0
TypeScript SDKv6.1.0
Java SDKv6.1.0
OpenClaw pluginv1.3.2
Claude Code / Cursor pluginsv0.5.2
Codex pluginv0.4.2

Who is affected​

  • Hand-written SDK users on TS / Python / Go / Java: bump to surface the Plugin Batch 1 fields on mcpCheckInput / mcpCheckOutput (mcp_check_input / mcp_check_output / MCPCheckInput / MCPCheckOutput in the per-language casing). All additive — existing callers keep compiling.
  • Plugin authors: regenerate against the v7.4.3 spec to clear the Plugin Batch 1 baseline drift.
  • Code-generated client users: regenerate against docs/api/agent-api.yaml from v7.4.3 to pick up the new MCPCheckInputResponse / MCPCheckOutputResponse fields and the three new explainability schemas.
  • Operators of the platform: v7.4.3 is documentation-grade with no behavior change; rolling restart suffices.
Last updated on