AxonFlow v7.9.0 Release Notes
Decision-record + observability release. Closes the read-side audit loop: callers can now list recorded policy decisions, explain any specific one, and read the policy version that was active at decision time. Same release brings anonymous platform-level startup telemetry (agent + orchestrator) so deployments that never instantiate a language SDK still register with adoption analytics, plus a v1 cleanup of the telemetry-receiver schema.
No breaking changes for self-hosted Enterprise deployments. Existing SDK and plugin pings continue to work unchanged — every schema addition is additive on the wire.
V1 customer-facing surfaces shipping in this release:
GET /api/v1/decisionslist endpoint for paging recorded policy decisions. Companion to the/api/v1/decisions/{id}/explainendpoint shipped in v7.4.0 — callers can now both list and drill in, the complete read-side audit surface for "show me everything we blocked yesterday and why" workflows. Tier-aware caps (Free 24h × 5 max page; Pro 30d × 100; Self-hosted Evaluation 14d × 100; Self-hosted Enterprise full retention × 1000).list_recent_decisionsMCP tool wraps the new list endpoint. The AI in any host CLI (Cursor, Claude Code, Codex, OpenClaw) can now answer "what just got blocked?" inline without the user leaving their tool surface. Same tier caps as the HTTP endpoint.policy_version_at_decisionon the explain response. Records and surfaces the policy version that was active when the decision was made — so a compliance review of a decision made before a policy was edited can drill not just into which policy fired but the exact rule text the decision was made against. Additive field; existing readers ignore it cleanly.- Anonymous platform startup heartbeat (agent + orchestrator). One classification-only ping per binary per 7 days containing OS, arch, runtime version, deployment mode, license tier bucket, and environment class. No URLs, tokens, secrets, customer data, prompts, schemas, tenant IDs, request IDs, or plugin lists ever cross the boundary. Single opt-out lever — the same
AXONFLOW_TELEMETRY=offenv var the SDKs and plugins honor. Disclosure line printed on every send so operators can audit what leaves. Closes the gap where deployments that boot the platform viadocker compose upand never instantiate a language SDK appeared invisible to adoption analytics. - v1 telemetry schema additions on
POST /v1/ping. Five additive fields:telemetry_type(sdk/plugin/platform/synthetic— the emitter-class discriminator),component(agent/orchestrator— required whentelemetry_type=platform),license_tier(one ofCommunity/Evaluation/Professional/Enterprise/EnterprisePlus/unknown),environment_class(one oflambda/ecs_fargate/ecs_ec2/kubernetes/container/bare_metal/unknown), andstream(heartbeatdefault,sandboxfor sandbox-mode SDK clients). All five carry closed-enum normalization — unrecognized values bucket asunknownrather than producing HTTP 400. Existing pre-v8 SDK and plugin pings continue to work unchanged. - Rust SDK joins the language-SDK allowlist on the telemetry receiver. The Rust SDK preview can now route its anonymous heartbeat through
https://checkpoint.getaxonflow.com/v1/pingfor the first time, bringing Rust into parity with the four stable SDKs.
Companion plugin and SDK release planned same day. The four stable SDKs (Go / Python / TypeScript / Java) advance to v8.0.0 with the v1 telemetry-schema participation. The Rust SDK preview advances to v0.2.0 with a broader scope than the stable train: the new decision-history client API (list_decisions + an explain_decision example), an Anthropic interceptor (joining the existing OpenAI interceptor), central-checkpoint telemetry parity with the other four SDKs, an AxonFlowConfig::sandbox() convenience constructor for cross-SDK parity, and a URL-encoding fix that aligns path-parameter percent-encoding with the other SDKs. The four plugins (OpenClaw / Claude Code / Cursor / Codex) advance to v2.4.0 / v1.4.0 with v1-schema-aware telemetry emission and the list_recent_decisions MCP tool. Per-version detail tracked on each repo's release page; plugin tags + npm / ClawHub publishes follow on each repo's release schedule.
What's new
Decision history — list, explain, version provenance
The Decisions API gains a list endpoint that complements the existing per-decision /explain endpoint, plus an MCP-tool wrapper so the AI in any host CLI can drive the same workflow inline.
GET /api/v1/decisions — list recent policy decisions
Pages recorded policy decisions for the calling tenant. Tier-aware caps shape the lookback window and page size:
| Tier | Lookback window | Max page size |
|---|---|---|
| Free (Community SaaS) | 24 hours | 5 |
| Pro (Community SaaS) | 30 days | 100 |
| Self-hosted Evaluation | 14 days | 100 |
| Self-hosted Enterprise | full audit retention | 1000 |
Standard query parameters: since (RFC3339), decision (allow / deny / require_approval), policy_id, tool_signature, limit. Hitting a Free-tier cap returns the same V1 upgrade envelope used elsewhere across V1 — limit_type=decision_list_size, structured upgrade block with the Pro purchase URL.
Full reference at Decisions API.
list_recent_decisions MCP tool
A new tool on /api/v1/mcp-server lets the AI assistant in Cursor, Claude Code, Codex, or OpenClaw call the list endpoint inline. Same parameters as the HTTP endpoint; same tier-aware caps. The AI can now answer "what just got blocked?" without the user leaving their tool surface.
policy_version_at_decision on the explain payload
The /api/v1/decisions/{id}/explain response gains an additive policy_version_at_decision field that records the policy version active when the decision was made. Crucial for compliance review of decisions made before a policy was edited — the audit drill-in shows not just which policy fired but the exact rule text the decision was made against.
Existing readers ignore the field cleanly (additive only); new readers can use it to cross-reference against /api/v1/policies/{id}/versions/{n} for the original rule text.
Anonymous platform startup telemetry
The agent and orchestrator binaries now emit a single anonymous heartbeat per binary per 7 days at startup. One classification-only payload — OS, arch, runtime version, deployment mode, license tier bucket, and environment class. Cadence and stamp-on-delivery semantics mirror the SDK heartbeat (per-binary stamp file under the OS-native cache directory).
Privacy invariants:
- No URLs, tokens, secrets, customer data, prompts, schemas, tenant IDs, request IDs, or plugin lists cross the boundary.
- The configured AxonFlow URL itself is never sent — only an
endpoint_typeclassification (localhost/private_network/remote/community-saas/unknown). - Single opt-out:
AXONFLOW_TELEMETRY=off. Same env var the SDKs and plugins honor — one mental model across every binary and every emitter. - Disclosure line printed to stderr on every send so operators can audit what leaves:
[AxonFlow] Anonymous telemetry enabled. Opt out: AXONFLOW_TELEMETRY=off | https://docs.getaxonflow.com/docs/telemetry.
Closes the long-standing gap where deployments that boot the platform via docker compose up and never instantiate a language SDK appeared invisible to adoption analytics. Self-hosted Enterprise deployments that prefer to opt out can set AXONFLOW_TELEMETRY=off in the agent + orchestrator container env vars.
Full reference at Telemetry.
v1 telemetry schema additions on the receiver
Five additive fields on POST /v1/ping give the receiver a uniform shape across SDKs, plugins, the new platform startup ping, and a future server-side bridge stream:
| Field | Values | What it discriminates |
|---|---|---|
telemetry_type | sdk / plugin / platform / synthetic | The emitter class. Empty accepted during the v1 migration window for pre-v8 SDK / plugin pings; class is inferred from sdk-field membership in that case. |
component | agent / orchestrator | Required when telemetry_type=platform; rejected on other classes. |
license_tier | Community / Evaluation / Professional / Enterprise / EnterprisePlus / unknown | The AxonFlow-issued tier the binary is operating under. Same value AxonFlow itself assigned at issuance. |
environment_class | lambda / ecs_fargate / ecs_ec2 / kubernetes / container / bare_metal / unknown | Coarse runtime-environment classification — categorical only, no host names or instance metadata. |
stream | "" (defaults heartbeat) / heartbeat / sandbox | Self-classifies the heartbeat sub-stream. Sandbox-mode SDK clients self-classify so dev pings stay distinguishable from production heartbeat in analytics. |
All five fields carry closed-enum normalization. Unrecognized non-empty values bucket as unknown server-side rather than producing HTTP 400 — fail-soft so a lagging or misconfigured emitter never gets rejected silently. Empty values pass through (preserves back-compat for pre-v8 SDK / plugin pings).
The two-route ingress on the receiver is unchanged: POST /v1/ping is public and unauthenticated; POST /v1/ping/internal is SigV4-authenticated and reserved for AxonFlow-operated server-side bridges. Public callers cannot reach the internal route; the internal route accepts only telemetry_type=synthetic.
Rust SDK joins the language-SDK allowlist + broader v0.2.0 scope
The receiver now accepts "rust" as a valid sdk value when telemetry_type=sdk, and the latest-version response includes a Rust field so cold-start fetchers pull the current crates.io tag. Rust SDK v0.2.0 is the companion preview release. Beyond the central-telemetry move, v0.2.0 ships:
client.list_decisions(opts)— the new decision-history client API mirroringGET /api/v1/decisions. Companion to the carried-forwardclient.explain_decision(decision_id). Both backed byexamples/list_decisions/andexamples/explain_decision/.- Anthropic interceptor — adds Anthropic alongside the existing OpenAI interceptor.
- Central-checkpoint telemetry parity. The Rust SDK now routes the heartbeat through
https://checkpoint.getaxonflow.com/v1/pingand emits the cross-SDK v1 schema (telemetry_type,deployment_mode,endpoint_type,instance_id,stream) in adoption-analytics parity with the four stable SDKs. AxonFlowConfig::sandbox(client_id, client_secret)convenience constructor — parity with Go'sSandbox(), Python's.sandbox(), TypeScript'sAxonFlow.sandbox(), Java'sAxonFlow.sandbox(url).- URL-encoding parity fix — path parameters (
connector_id,plan_id,decision_id) were over-escaping the RFC-3986 unreserved characters_,-,.,~. Connector IDs likeamadeus-travelare now wire-correct (amadeus-travelrather thanamadeus%2Dtravel).
Privacy improvements on the telemetry receiver
Two privacy-side changes on the central telemetry pipeline:
- Salted SHA-256 source-IP hashing. The receiver previously hashed the source IP with bare SHA-256 before persistence. Bare SHA-256 of an IP is reversible by exhaustive enumeration of the IPv4 address space. The receiver now uses salted SHA-256 with a server-side rotating salt, so the persisted hash is unrecoverable by enumeration. The salt rotates annually; rotation does not invalidate prior records (each record carries the salt version it was hashed under).
- 90-day operational-log source-IP retention disclosed. Operational logs (CloudWatch + API Gateway access logs) on the central telemetry pipeline retain the source IP for 90 days for incident-response and abuse-prevention purposes. This was previously implicit in operating a hosted service; the privacy policy now makes the retention boundary explicit. The persisted DynamoDB telemetry record continues to store only the salted hash, never the raw IP.
Both changes apply only to the central telemetry receiver at checkpoint.getaxonflow.com. Self-hosted deployments are unaffected.
Full disclosure at the Privacy Policy.
Fixed
- Community SaaS daily-cap 429 events now persist with full attribution. Previously the auth middleware populated the telemetry tenant_id after the daily-cap check, so rate-limit rejections terminated before attribution and the telemetry table was blind to the very rejections it should have been counting. Tenant_id now resolves immediately after auth, before the daily-cap gate, so every 429 event ingests with full attribution. Affects Community SaaS only; self-hosted deployments don't run the same daily-cap path.
Enterprise
Changed
RecommendedPluginVersionadvertised in/healthbumps to claude / cursor / codex 1.4.0 and openclaw 2.4.0.MinPluginVersionfloors stay at 1.0.0 / 2.0.0 — pre-1.x plugins ran the pre-DNT-removal contract and remain blocked; pre-V1-Plugin-Pro plugins continue to work but log an actionable upgrade warning on every governed call.RecommendedSDKVersionadvances to v8.0.0 for the four stable SDKs (Go / Python / TypeScript / Java). The v8 train carries the v1 telemetry-schema participation and removes the programmatictelemetry: falseconfig field — the env varAXONFLOW_TELEMETRY=offis now the sole opt-out across all five SDKs. Pre-v8 SDKs continue to work unchanged via the migration window on the receiver.- Rust SDK floor advances to v0.2.0 (preview) with the central-checkpoint heartbeat path.
Upgrade notes
This is a server-side + plugin-side + SDK-side release with no breaking changes:
- Self-hosted operators can upgrade the platform image to v7.9.0 with no configuration changes. The new platform startup ping respects
AXONFLOW_TELEMETRY=off; set it in the agent + orchestrator container env if you prefer to opt out. Tier-aware caps on the newGET /api/v1/decisionsendpoint follow your existing license tier — no per-tier configuration required. - Plugin users can upgrade to v1.4.0 (claude / cursor / codex) or v2.4.0 (openclaw) for the new
list_recent_decisionsMCP tool. Existing plugin versions continue to work; the new tool simply isn't available intools/listuntil the plugin upgrades. - SDK users can upgrade to v8.0.0 (go / python / typescript / java) or v0.2.0 (rust) on the next dependency refresh. The v8 train is forward-compatible — existing v7.x SDK callers continue to work via the v1 telemetry migration window on the receiver, with no wire-level disruption.
See also
- Telemetry — what the platform startup ping collects and how to opt out
- Decisions API — full reference for the new
GET /api/v1/decisionslist endpoint - Plugin Pro — V1 Plugin Pro tier the new tier caps apply to
- Privacy Policy — what the central telemetry receiver collects and retains
