- frontend-api.md (#986): the list, search, and recent routes return bare
JSON arrays, not `{ "workspaces": … }`-style wrappers (the route tests
assert `as_array()`); a page read returns `body_markdown`, not `body`; a
search hit carries workspace/project/kind and no `id`.
- windows.md (#758): native `ai-memory upgrade` is done (#801/#802), not
in-progress.
- managed-workstreams.md + support matrix (#987): document the Codex shared
daemon handing hooks a stale AI_MEMORY_RUN_ID and the `--no-daemon`
workaround until the server-side fix lands.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01MDbhmszrjG9s5MrPrTuNtm
Adds a delimited "Support Tier: Experimental → Supported Exit Criteria"
section enumerating what native Windows support requires and its current
status from repository evidence: CI trigger coverage (done), the hook-bundle
Windows job (done), the #[cfg(windows)] regression coverage (in-progress),
.exe code-signing (deferred-pending-policy — cert + CI-secret decision, App
Control/Smart App Control implications), and a native upgrade path (#801/#802).
It is the checklist a maintainer uses to decide promotion; it does not claim one.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01MDbhmszrjG9s5MrPrTuNtm
A LocalSystem Windows service over a user-owned data dir trips libgit2's
dubious-ownership guard (CVE-2022-24765): every wiki commit fails with
code=Owner, but the failure was WARN-only, so capture kept working while
the wiki git history silently stopped advancing.
- Map an Owner-code git2 error to a distinct WikiError::GitOwner (the git
CLI fallback is skipped: it enforces the same guard and would refuse
identically). The owner check itself stays enabled (disabling it is
unsafe and reopens the CVE).
- Surface the startup baseline-checkpoint owner failure at ERROR with the
remedy (run the service as the owning user), classified through a small
testable seam.
- docs/windows.md Scenario E: recommend a <serviceaccount>, correct the
"only the data directory is account-sensitive" claim, and note the
WinSW error-1069 / stale-password gotcha for Microsoft-account / PIN /
Hello users.
A doctor wiki-git probe was considered but not added: doctor is
HTTP-only and never opens the store directly, so a probe would need a new
server endpoint — out of scope for a targeted fix.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01MDbhmszrjG9s5MrPrTuNtm
Forward-merge of the nine PRs that landed on main (the 2.0.4 batch: #642 auth
stale-bearer, #646/#640 LoginLimiter, #644 Cursor attribution, #650/#647
reindex manifest, #638 MCP routing, #652 CI docs, #645 dev-loop/build) into the
2.1 feature train, so release/2.1 carries every fix before 2.1.0 is cut.
Conflicts resolved:
- crates/ai-memory-wiki/src/wiki.rs: 2.1's per-page write lock (page_locks,
#607) and main's manifested_scopes memo (#650) are independent additions to
the same struct/imports/constructor — kept both; imports merged to
{HashMap, HashSet}.
- CHANGELOG.md: [Unreleased] now carries 2.1's ### Added features above main's
### Changed + ### Fixed (the 2.0.4 fixes), Keep-a-Changelog order, single
[2.0.3] section preserved.
- crates/ai-memory-llm/tests/extra_headers_on_the_wire.rs (2.1's #606 test)
relocated into tests/suite/ and declared in mod.rs to satisfy #645's
one-test-binary-per-crate harness convention (caught by the repo_layout guard).
fmt, clippy -D warnings, llm harness, and the repo_layout guard all green.
The edit-to-result loop was ~380s for the workspace on macOS and needed an
environment variable on every command. This makes `cargo t` the whole story
on macOS, Linux, and Windows, with numbers measured along the way.
Build
- `[profile.dev]` keeps only line tables (full debuginfo put ~190 MB of
DWARF in each test binary and made the build linker-bound); dependencies
build at opt-level 1 with no debuginfo; proc macros and build scripts at
opt-level 3, since they are run once per dependent crate.
- Test binaries: 78 to 11 in the everyday loop (13 under `--workspace`).
Each one is a link and, on macOS (Gatekeeper) and Windows (Defender), a
first-run malware scan of the whole file, paid serially by nextest's list
phase before the first test starts. Integration tests now live in
`tests/suite/` and compile into their crate's own test harness (`mod.rs`,
included from `src/lib.rs` under `#[cfg(test)]`, with `extern crate self`
so they keep addressing the public API by crate name). Only the CLI keeps
a separate `suite` target, because its tests run the built executable.
The evals harness leaves `default-members`, so a bare `cargo t` skips its
two binaries while `--workspace` (CI, the hook, `cargo tf`) still builds
them. A repo-layout test fails on an undeclared suite file, a stray
top-level `tests/*.rs`, or a `mod.rs` that `lib.rs` never includes.
- `ai-memory-cli` gains a lib target; `main.rs` is a shim. 806 tests that
lived in the bin are reachable, and `--lib` runs skip the 127 MB binary.
- The web crate's vendored `static/tailwind.css` is the default on every
build, so nothing needs `TAILWIND_SKIP=1` any more: every release, Docker,
and CI path already used the vendored file, and the download branch only
ever ran for developers who forgot the flag (and then rewrote the source
tree as a side effect). `TAILWIND_BUILD=1 cargo build -p ai-memory-web`
regenerates it explicitly. CI runs that on Linux and fails if the
committed file is stale, a check that did not exist before; the committed
file reproduces byte for byte today.
- `tokenizers` aligned on one version instead of the 0.21 pin plus the 0.22
candle pulled in.
Test tiers
- `.config/nextest.toml`: the `default` profile skips any test whose module
path has a segment starting with `slow` or `stress` (`packaging::slow::*`
drives real wrapper scripts and fake container engines at 10-20s each;
`stress_*` modules hammer concurrency), reports every failure in one run,
and marks anything over 5s in its summary so a new slow test is visible
the day it lands. `full` runs everything. `ci` keeps its retries and
writes JUnit.
- `.cargo/config.toml` holds two aliases and nothing else: `cargo t` (default
members) and `cargo tf` (`--workspace -P full`). `cargo t -p <crate>`
builds just that crate. Neither passes `--all-targets`: there are no
examples or benches, and it only added harnesses for two `test = false`
targets.
- `scripts/install-git-hooks.sh` installs an opt-in pre-push hook that runs
the full tier, touching only its own marked block. Two independent things
run the skipped tier: that hook, and CI, which uses `cargo test` and never
reads the nextest config.
Slow tests fixed rather than tiered
- `project_observations` in the consolidator trimmed an over-budget
projection one observation at a time, re-rendering the whole text and
re-scoring every remaining candidate after each removal. Each score scans
the body, so 256 observations of 4k chars cost ~65k body scans per prompt:
14s in production consolidation, exactly as in the unit test. Scores and
per-block sizes are now computed once and the prune subtracts; output is
unchanged and pinned by the existing tests. 13.9s to 0.18s.
- Windows takes ~2s to refuse a loopback connect, so every hook test that
posted to a closed port paid 2s per request. `dead_http_endpoint()` in the
new `ai-memory-test-support` crate accepts and closes instead, with a
fallback to the closed port where binding is denied. devin hook tests:
4.2s to 0.15s each.
- The store unit fixture opened a file-backed SQLite with the default
rollback journal and synchronous=FULL, so ~120 parallel fixtures fsynced
every transaction. journal_mode=MEMORY + synchronous=OFF: 242s to 89s of
test time, p90 1.6s to 0.5s.
- Windows-only tests resolve `powershell.exe` or `pwsh.exe` once per process
and the auto-improve eval fixtures are `.ps1` scripts instead of cmd.exe
batch files; a post-bind settle sleep is gone; the two unpinned
multi-thread tokio tests pin `worker_threads = 4`. The four copies of the
PowerShell resolver and the mcp suite's duplicated `post`/`get` helpers are
now one each.
Not done, with the numbers in AGENTS.md: nextest vs in-process libtest is a
wash per crate and a rout for the workspace (20s vs 309s); the
`local-embeddings` default feature costs ~50s of cold build and ~27 MB per
binary but under a second per relink, so it stays a product default.
Measured: workspace loop ~380s to ~150s on macOS; on a 32-thread Windows box
the warm everyday run is 20s of test time across 2919 tests in 11 binaries,
and the rebuild after a core edit is 13s of cargo with lld plus the
first-run scans.
#545 landed Scenario E with a verification note saying the WinSW steps had
been checked against upstream documentation and the ai-memory CLI surface
but never executed on Windows, and left #530 open for exactly that. This
runs them.
Executed on 2026-08-31 on Windows 11 25H2 (build 26200.9168) with WinSW
v2.12.0 (WinSW-x64.exe) and ai-memory v1.38.0, from an elevated PowerShell
session, against a throwaway service id, port and data directory so the
machine's real instance was never touched. Confirmed: install; start; the
service Running as LocalSystem with StartType Automatic; an MCP
`initialize` answered with HTTP 200 over the bound port; the absolute
`--data-dir` honoured, with systemprofile\AppData\Local\ai-memory never
created; crash recovery, force-killing the wrapped ai-memory.exe and seeing
a replacement answer 8s later, consistent with the 5-second <onfailure>
delay plus startup; and a clean stop + uninstall leaving no service and no
stray process.
Two claims the note now bounds explicitly rather than leaving open. The
service was configured with StartType Automatic, but boot-time startup was
not independently exercised, so the note says that instead of inferring the
outcome. And at the time of this validation v2.12.0 was the latest stable
WinSW release while the published 3.x releases - which the previous note
pointed at - were prereleases; dating the claim keeps it from silently
going stale.
Refs #530.
Scenarios C and D both ended at `ai-memory serve` in a foreground
terminal while Linux got `Restart=on-failure` from the packaged systemd
units. Document WinSW as the equivalent supervisor, and lead with the
trap rather than the recipe.
A Scheduled Task whose action is a PowerShell script calling
`Start-Process` looks correct and is silently killed at the next reboot:
`Start-Process` returns immediately, the script exits, and Task Scheduler
tears down the job object the still-running server was never detached
from. Its only symptom is a permanently green `LastTaskResult = 0`, which
is why it costs hours to find. Reported and root-caused with event-log
evidence by @gabrielscharb.
Also covered: why `sc create` against `ai-memory.exe` cannot work (no SCM
control-code dispatcher, and none is planned - the resiliency belongs in
the supervisor, as it does on Linux); the corrected Task Scheduler shape
for anyone who wants one anyway, including the default 3-day execution
time limit that stops a healthy server; and why the WinSW config needs
absolute paths, since a service runs as LocalSystem and `%LOCALAPPDATA%`
would resolve to the system profile and quietly serve an empty data
directory.
The warning is reachable from the Rule Of Thumb, from the end of both
Scenario C and D, and from the caveats list, so someone who already built
the broken task finds it without reading top to bottom.
Refs #530 — deliberately left open pending verification on real Windows
hardware (the WinSW steps here were checked against upstream docs and the
ai-memory CLI surface, but not executed on Windows).
Claude-Session: https://claude.ai/code/session_01MDbhmszrjG9s5MrPrTuNtm
Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
A native Windows machine with Smart App Control or App Control for
Business enforced cannot build the workspace: cargo compiles each crate's
`build.rs` into an unsigned executable under `target\debug\build\`, and
those policies block unsigned binaries from running out of user-writable
directories. The build dies on `proc-macro2` with `os error 4551` before
reaching any ai-memory code, so it reads as a broken Rust install rather
than a machine policy.
Found by @CaioCoelhoChaves while running the #478 measurements — the
"report a build failure too" case, which turned out to be worth as much as
the numbers.
Documents the symptom, why re-installing Rust will not help, and the path
exclusion that does.
The PowerShell wrapper runs every CLI command inside a short-lived helper
container, so the CLI's default http://127.0.0.1:49374 resolved to that
helper rather than to the Windows host. A healthy loopback-published
server was therefore unreachable from `ai-memory status` with
"Connection refused (os error 111)", while curl from PowerShell worked.
Docker Desktop gives Linux containers no host networking on Windows, the
same constraint the POSIX wrapper's Darwin arm already handles for macOS
(issue #107). Port that semantics rather than rewriting the address
globally: thin-client commands get host.docker.internal injected, while
install-mcp/install-hooks/setup-agent keep rendering the loopback URL
into host-side agent config, where host.docker.internal does not resolve.
An explicit AI_MEMORY_SERVER_URL still wins, so remote/homelab servers
are unaffected.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Co-authored-by: Cursor <cursoragent@cursor.com>
Add first-party lifecycle capture for the AWS Kiro CLI (#355). The
binary ships two agent engines with incompatible hook surfaces, so each
is selected explicitly and never guessed:
- `install-hooks --agent kiro-cli` merges five flat camelCase entries
(agentSpawn, userPromptSubmit, preToolUse, postToolUse, stop) into
every existing v2 agent config under ~/.kiro/agents/. Entries carry no
matcher key (absent = every tool; empty string matches nothing) and no
type key (the v2 Hook schema has neither), and agentSpawn raises
max_output_size to 64 KiB so an injected handoff + brief is not
truncated. The v2 engine has no global hook surface and the built-in
default agent has no file on disk, so the installer updates existing
configs and bails with guidance when none exist instead of inventing
an agent that would never be active.
- `install-hooks --agent kiro-cli-v3` writes the standalone versioned
hooks file ~/.kiro/hooks/ai-memory.json (PascalCase triggers, command
actions, timeout in seconds) for the early-access v3 engine, never
touching other files in the hooks directory and preserving
non-ai-memory entries inside ours.
Both surfaces honor $KIRO_HOME (verified against kiro-cli 2.16.0),
share one hooks/kiro-cli script bundle, uninstall cleanly, and keep
capture fail-open: hooks always exit 0 and print nothing on capture
paths, because exit code 2 blocks the tool call and session-start /
user-prompt stdout is added to the agent context on both engines. For
the same reason the native `ai-memory hook` command suppresses its `{}`
protocol line for kiro-cli and prints a fetched session-start handoff
raw (no hookSpecificOutput envelope — Kiro documents none).
Kiro tool payloads (tool_name/tool_input, tool_response.success) join
the capture policy with fixture vectors, including fs_read's batched
operations path extraction; fs_read/fs_write/execute_bash join the tool
family map. The v3 stdin payload shape is not publicly documented and
extraction stays verified on the v2 shape only (documented as such).
Also add `?flavor=bedrock` as an alias of the Moonshot root-schema
flattening: Kiro talks to Amazon Bedrock's Converse API, which rejects
root-level anyOf/oneOf/allOf in tool schemas, so a manually configured
~/.kiro/settings/mcp.json can point at …/mcp?flavor=bedrock (#351).
Contracts verified against kiro-cli 2.16.0 (binary surface probed
locally), kiro.dev's v2/v3 hook references, and the shipping HookTrigger
implementation in aws/amazon-q-developer-cli.
Closes#355.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01LJvj7D7czyZzqk4pDXgLxY
The per-request timeouts (drain POST, handoff GET) and the session-boundary
budgets (session-start cleanup, session-end flush) read ms overrides from
AI_MEMORY_HOOK_DRAIN_TIMEOUT_MS / _HANDOFF_TIMEOUT_MS / _START_BUDGET_MS /
_END_BUDGET_MS, defaulting to today's values (3s / 3s / 3s / 10s). Read at
hook runtime (no re-install-hooks); non-numeric or zero falls back to default.
`for_bash_runner` now returns `PosixNative` on native macOS/Linux (mirroring
Windows), so Claude Code hooks invoke `ai-memory hook` — getting the spool +
OIDC fallback — instead of the `.sh` script that POSTs via curl. The Docker
wrapper (`bin/ai-memory`) forces `AI_MEMORY_HOOK_PLATFORM=posix`, so its
host-rendered config keeps the `.sh` scripts (the host has no local binary).
Validated in a Linux container (runtime-source image): install-hooks renders
the binary command by default and `.sh` when `posix` is forced; the rendered
hook spools to `<data_dir>/hook-spool` (0600), drains on session-end, and the
server writes the session page.
Two related capabilities for headless lifecycle hooks behind an IdP and
against remote/slow servers.
OIDC device-flow auth (crates/ai-memory-llm/src/oidc.rs, auth.rs, cli.rs):
`ai-memory auth login oidc-device --issuer <kc> --client-id <id>` runs the
OIDC device-authorization grant against any issuer (e.g. Keycloak), storing
access+refresh in the shared auth.json. A headless hook then authenticates as
the individual developer (per-user JWT, attributed via preferred_username)
instead of a shared static token. The server is unchanged — its auth layer
already validates the realm JWT on the hook routes (mcp:read).
Spool-based capture (hook_spool.rs, hook.rs):
Per-tool-call hooks append the event to a local spool (instant, never blocks
the agent) instead of POSTing synchronously. The spool drains at session
boundaries (cleanup on session-start, main flush on session-end), so capture
is reliable against a remote/slow server with no dropped events and no
per-tool-call network latency. Each event carries its own auth (static token
inline; OIDC resolved+refreshed at drain). Dead events are pruned by attempts
+ age. The session-start handoff GET stays synchronous with a larger timeout.
Also: opt-in AI_MEMORY_HOOK_PLATFORM=posix-native so native Linux/macOS
installs get the same spool + OIDC path (the default stays .sh, Docker-safe).
Tested: fmt/clippy clean; unit tests for oidc/spool/render; dockerized e2e
(hot path never blocks, backlog recovery, handoff read, OIDC JWT accepted on
/hook with per-user attribution).
Add a `windows` job to release.yml that builds ai-memory-cli on
windows-latest and publishes ai-memory-windows-x86_64.zip alongside the
Linux tarballs. The zip mirrors the Linux release layout minus the
Linux-only service assets (packaging/systemd|sysusers|tmpfiles|env): the
.exe, the full hooks bundle (.ps1 + .sh), the default config template,
README/LICENSE and docs/{install,windows}.md. Checksum is emitted in
sha256sum format so the release body checksums block stays uniform.
Wire the job into github-release `needs` so the release waits for the
Windows artifact, add a Windows line to the release body, and document a
no-toolchain install path as a new scenario in docs/windows.md. This
gives native-Windows users the fast windows-native hook path without a
Rust toolchain or Docker.
Post-merge audit Phase 4 surfaced two doc-staleness items the
per-PR audits couldn't see in isolation:
- docs/windows.md mentioned only `AI_MEMORY_HOOK_PLATFORM=windows-bash`
(the escape-hatch value). The default `windows-native` value PR #84
introduced was never named — an operator reading the doc to opt
back into bash had no list of valid platform values to choose from.
- docs/frontend-api.md endpoint reference omitted the new
`GET /favicon.ico` route PR #79 added. Added §4.10 describing it.
The favicon section also nails down the bearer-auth answer (it rides
the `/web/*` HTTP Basic credentials, not exempt) so a future
"why isn't my favicon showing" issue points at the auth answer
directly.
No code touched.
Emit lifecycle hooks via a new `ai-memory hook` subcommand instead of
spawning `bash -c` + a `.sh` script. On Windows, Claude Code hooks now
default to this native binary call, cutting per-tool-call overhead from
~735ms to ~175ms (no Git Bash + cat/sed/curl child-process spawns).
- New `WindowsNative` platform in render_shared; POSIX and the
Docker/setup-agent flow keep emitting the shell command. Opt back into
Git Bash with AI_MEMORY_HOOK_PLATFORM=windows-bash.
- Command is double-quoted: Claude Code runs hooks via cmd.exe, which
rejects POSIX single quotes (double quotes work in cmd.exe and bash).
- Best-effort with shell-parity timeouts (0.5s POST, 1s handoff GET);
fast-path before config/tracing init keeps stdout clean.
- Reuses the bundled .sh/.ps1 scripts as fallback. Parity tests added;
docs/windows.md updated.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
AkitaOnRails