vendoring ships fipsagents 0.9.0 while PyPI is on 0.31.2, and `vendor --update` reinforces it

[wjatx]

Summary

Both fips-agents create agent --vendored and fips-agents vendor --update install fipsagents 0.9.0, released 2026-04-24. PyPI currently ships 0.31.2. That is 32 releases and roughly four months behind, and there is no warning at any point in the flow.

The second command is the more serious half: vendor --update is the documented remedy for a stale vendored tree ("Use --update to refresh an already-vendored project with the latest upstream source"), but it re-clones this repo, whose bundled copy is also 0.9.0. So the command that exists to fix staleness cannot, and a user who runs it reasonably concludes they are current.

Reproduction

Environment: fips-agents-cli 0.16.0, macOS (Apple M3), Python 3.11+. Observed 2026-08-16.

fips-agents create agent my-agent --vendored --local --yes

Output includes:

✓ Copied fipsagents source to src/fipsagents/
✓ Wrote VENDORED marker (version 0.9.0, commit unknown)

Then, in the generated project:

fips-agents vendor --update

Output:

⠴ Cloning agent-template repo...
✓ Copied fipsagents source to src/fipsagents/
✓ Wrote VENDORED marker (version 0.9.0, commit aabdf3b)

The resulting src/fipsagents/VENDORED:

version: 0.9.0
source: https://github.com/fips-agents/agent-template
commit: aabdf3b0e0709adcdb3670c0874fb81f7973afd3
commit_short: aabdf3b

Evidence

• PyPI fipsagents latest is 0.31.2; 0.9.0 was uploaded 2026-04-24T20:02:22; 32 releases exist between them.
• The VENDORED marker names this repository as the source, and --update re-clones it rather than reading PyPI or a monorepo path, so both paths converge on whatever this repo bundles.
• On the first create, commit is recorded as unknown, so a user cannot even tell which upstream revision they received without running --update afterwards.

Impact

The stated purpose of --vendored is "full control over the framework" — i.e. it is chosen precisely by users who intend to modify BaseAgent. Those modifications land on a four-month-old base, and the eventual reconciliation against 0.31.x is a merge across 32 releases rather than a rebase onto current.

In our case the intent was to add a native Anthropic path to baseagent/llm.py. Doing that against 0.9.0 would have meant re-doing it later, which is what prompted the check.

Where this probably lives

The bundled source in this repository is the proximate cause. Whether the fix belongs here (refresh the bundled copy, and keep it refreshed on release) or in fips-agents-cli (vendor from the PyPI sdist or a monorepo path rather than from this repo's snapshot) is a call for whoever owns the vendoring step. The --update behaviour specifically reads like a CLI-side sourcing decision.

Suggested fix

Whichever side owns it, two properties seem worth having:

1. Vendoring sources current fipsagents, not a snapshot that drifts. The PyPI sdist works well for this: fipsagents-0.31.2.tar.gz carries src/fipsagents/ with the identical layout and the same 22 baseagent/*.py modules as the bundled 0.9.0, and compiles clean as a drop-in replacement. We verified this by swapping it in by hand.
2. The version is asserted, not just recorded. If vendoring resolves a version behind the user's back, printing vendored fipsagents 0.9.0 (PyPI latest: 0.31.2) would have surfaced this immediately. Silently writing a marker nobody reads until something breaks is the failure mode here.

Workaround for anyone hitting this now

Replace src/fipsagents/{baseagent,serialization,server,subagents,workflow,__init__.py} with the contents of the PyPI sdist, and note in the VENDORED marker that re-running either CLI command will silently downgrade the tree again.