Reported issues for AXF

Pod holds 17 of 24 problems reported by people outside the maintainer team. Issues filed by the project's own owners, members and collaborators are excluded entirely — a maintainer's release checklist is not a warning to a prospective user.

Back to AXF.

Most discussed

[Dogfood] Report dirty-worktree source provenance in cycle receipts

Problem

STFC Mod dogfood issue Guffawaffle/stfc-mod#189 showed that a cycle can build and deploy dirty working-tree source while its receipt names only the branch HEAD commit.

The build and deployed binary hashes matched, but the named commit did not contain the diagnostic source that produced the DLL. The receipt can therefore be read as stronger source provenance than it actually provides.

Required behavior

When the selected repository is dirty, the cycle/deploy receipt must disclose

Read the thread · 2026-07-27 · open · 2 comments

Enforce a trusted invocation ceiling and decision-bound receipt on every AXF execution path

Threatened boundary

Principal, tenant, workspace, repository, capability, arguments, lifecycle, credentials, and execution evidence.

Attack / failure scenario

An MCP caller chooses arbitrary projectRoot, executionRoot, target, arguments, capability, and allowAnyLifecycle, then invokes an active write/network capability without a principal- or task-bound grant. The transient result is later treated as evidence even though it is not bound to an authority decision or immutable source

Read the thread · 2026-07-23 · open · 2 comments

Add interpreter-aware execution targets for PowerShell and Windows script launchers

Problem

The generic CLI adapter is currently Unix-shaped: it spawns the declared command directly and assumes the OS can execute it as-is. In the Windows stfc-mod integration, spawning .cmd directly failed with EINVAL, and the reliable path was to invoke pwsh -File ...\ax.ps1 explicitly inside the provider integration.

That platform handling currently leaks into each integration instead of living in the framework.

Why this matters

Cross-platform execution differences should be

Read the thread · 2026-04-24 · closed · 2 comments

Preserve structured provider output when an MCP capability exits nonzero

Dogfood report

An AXF MCP run of global.stfc-mod-private.pure-tests failed with process status 1. Both standard and diagnostic response modes returned only EXECUTION_FAILED, status: 1, and data: null.

The underlying CLI invocation returned valid structured JSON containing the actionable build failure and output tails. Running that exact launch plan directly exposed the compiler error immediately.

Expected

When a provider exits nonzero but emits valid structured output, the MC

Read the thread · 2026-07-25 · closed · 1 comment

Classify and minimize sensitive capability result data

Threatened boundary

PHI, credentials, and other sensitive provider/capability output returned through AXF, logs, traces, caches, and receipts.

Attack / failure scenario

A provider returns patient data or a token inside capability data. AXF's framework diagnostics are redacted, but top-level result data is intentionally preserved and reaches the MCP client or downstream evidence surface without a declared audience, purpose, retention, or minimization policy.

Current behavior and ev

Read the thread · 2026-07-23 · open · 1 comment

Make adapter discovery inert and bind executable code to an authorized digest

Threatened boundary

Repository code execution during supposedly read-only AXF discovery, inspect, guide, and doctor operations.

Attack / failure scenario

A repository supplies a private adapter with malicious top-level JavaScript. AXF scans and imports it merely because an agent requests a read-only inspection operation, executing code before any capability decision.

Current behavior and evidence

src/core/adapter-loader.js scans project/toolspace adapters, weakly validates manife

Read the thread · 2026-07-23 · open · 1 comment

Improve AXF capability discovery and missing-capability diagnostics

Problem statement

AXF execution is ahead of AXF discovery.

In day-to-day operator use, list and inspect eventually expose enough detail, but the path to that detail is still too implicit:

• list can show a merged capability view without making provenance obvious at first glance.
• imported families, framework capabilities, and workspace-bound capabilities are not clearly distinguished in the primary discovery surface.
• notes such as workspace '<root>' has no axf manifests yet can

Read the thread · 2026-06-07 · closed · 1 comment

Framework Lex capabilities depend on bare lex command on PATH

Summary

@smartergpt/axf@0.1.6 advertises framework-global Lex capabilities such as global.lex.note, global.lex.recall, and global.lex.status, but those capabilities currently execute a bare lex command from PATH.

That makes the framework-global surface dependent on an unrelated global npm shim. If lex is not on PATH, AXF MCP still lists/inspects the capabilities, but running them fails.

Observed Behavior

With AXF MCP pointed at a workspace that has an `axf.workspace.jso

Read the thread · 2026-06-06 · closed · 1 comment

Most recent

MCP command resolution misses native Windows Path casing

Problem

On Windows, axf mcp snapshots process.env into a plain object. Native environment key casing is commonly Path, but AXF command resolution reads only PATH. A CLI capability such as global.lex.status therefore resolves normally through axf run yet fails through MCP with spawnSync lex ENOENT.

Root cause

The live process.env object is case-insensitive on Windows; the spread snapshot is not. PATH, PATHEXT, and ComSpec lookups must preserve Windows case-insensiti

Read the thread · 2026-08-29 · closed · 0 comments

Add typed awaitable completions and global.await.external to AXF

Objective

Make externally owned completion a first-class, inspectable AXF contract without turning AXF into a scheduler.

Slice 1 scope

• Add the versioned axf/awaitable/v1 descriptor and axf/await-result/v1 result contracts.
• Add an optional capability-manifest completion declaration.
• Preserve bounded top-level typed await-external continuations across family synthesis, execution, CLI, and MCP response profiles.
• Add global.await.external behind AXF's existing single axf

Read the thread · 2026-08-04 · closed · 0 comments

MCP capability search should explain zero results from multi-token all-term matching

Dogfood context

While restoring STFC through the project-local AXF family, these searches returned an empty capability list:

• search: "cycle stfc game releasedbg"
• search: "lifecycle"

The same router/project roots with search: "cycle" immediately returned:

• global.stfc-mod-private.cycle
• global.stfc-mod-private.postflight
• global.stfc-mod-private.preflight

The project binding and imported private family were healthy. The initial empty result therefore looked like capabil

Read the thread · 2026-07-27 · closed · 0 comments

Make agent-facing responses context-efficient by default

Problem

AI agents are AXF's primary, first-class consumers, but AXF's MCP responses currently spend substantial context on framework metadata rather than capability results.

A trivial successful run currently produces 1,523 minified JSON characters. Repeated legacy workspace aliases account for 845 characters (55.5%), before the MCP response also mirrors the payload as a pretty-printed text block. The same project/execution binding can appear up to eight times.

The existing compact opt

Read the thread · 2026-07-17 · closed · 0 comments

Scope framework CLI flags without reserving downstream argument names

Problem

AXF currently applies a repository-wide RESERVED_ARG_NAMES policy to imported command families. This rejects common downstream arguments such as --limit, --search, and --all even though those names are only AXF options on other subcommands and already pass through correctly during axf run.

The current policy also drifts from runtime behavior:

• json, any-lifecycle, and allow-draft are consumed/stripped during run.
• workspace/root flags are extracted before dispat

Read the thread · 2026-07-16 · closed · 0 comments

Agent ergonomics: detect and update stale Codex MCP package pins

Problem

A machine can have the current AXF CLI installed globally while Codex silently launches an old AXF MCP package from ~/.codex/config.toml.

Observed today:

• global CLI: @smartergpt/axf@1.1.0
• Codex MCP hook: npx --package @smartergpt/axf@0.2.1 axf mcp
• result: AXF worked in the shell, but the current Codex session did not expose the updated router/capabilities

This is exactly the kind of integration drift that causes an agent to fall back to shell discovery or brute force w

Read the thread · 2026-07-11 · closed · 0 comments

Add intent-oriented workflow entrypoints for agent bootstrap

Problem

AXF's canonical capability model is precise, but an arriving agent still has to understand the framework vocabulary before it can do ordinary workflow work.

In a real STFC Codex session, the AXF MCP router was present but lazy/hidden behind one tool. A workspace-bound list returned 73 capabilities and roughly 78 KB of manifest JSON. The repo guidance said to use AXF/Lex first, but the caller still had to infer which canonical IDs represented the three basic intents:

• establish c

Read the thread · 2026-07-11 · closed · 0 comments

Stop emitting host-specific /srv provider paths for installed capabilities

Problem statement

global.stfc-mod.cycle is discoverable through AXF CLI on this Windows host, but it cannot run because the installed capability resolves to a hardcoded /srv/... provider script path that does not exist here.

From D:\dev\stfc-mod:

npx axf inspect global.stfc-mod.cycle --json

Observed launch plan / execution target:

• command: node
• args prefix: /srv/stfc-mod/scripts/axf/stfc-provider.mjs, cycle
• cwd: `C:\Users\Guff\AppData\Roaming\npm\node_

Read the thread · 2026-06-06 · open · 0 comments

Decouple framework workspace discovery from capability execution workspace

Problem statement

Today AXF ties two different concerns to the same workspace root:

• capability discovery / framework-global availability
• child-process cwd for CLI capabilities

That becomes hostile in split-repo and integration scenarios.

Concrete observed behavior

In the current MCP setup, binding AXF to a marker-backed global workspace such as D:\dev\axf-global exposes global.lex.* correctly.

But those capabilities then execute with cwd set to that same workspace root, so Le

Read the thread · 2026-06-06 · closed · 0 comments

The remaining reports are on the project's issue tracker.