AFT
Gives coding agents a real IDE and OS: symbol-aware perception, precise edits, and a persistent background runtime.
- Source repo
- cortexkit/aft
- Stars
- ★ 334
- Last updated
- 1d ago
- License
- MIT
- Primary language
- Rust
- FA score
- 58/100 · Major gaps
At a glance
- Works with
- Portable with changes
- You'll need
- Typical use
- Developers already on OpenCode or Pi whose agent burns tokens reading whole files, who want aft_outline and aft_zoom to fetch structure instead.
- Main limitation
- Only three adapters exist today (OpenCode, Pi, and OMP via the Pi plugin); other hosts, MCP, and other frameworks are listed as future work.
- Source review
- 58/100 · Major gaps
What does this agent do, and when should you use it?
AFT is the "sensorimotor cortex" of the CortexKit plugin family: a Rust core binary plus thin per-harness adapters that let a coding agent see code as structure and edit it at the symbol level. The binary speaks JSON-over-stdio, keeps one process per project root alive across sessions, and bundles tree-sitter parsing for roughly 27 languages, symbol and call-graph analysis, trigram and semantic indexes, and an LSP client. Adapters exist for OpenCode (@cortexkit/aft-opencode) and Pi (@cortexkit/aft-pi), with OMP supported through the Pi plugin; they hoist the host's built-in read/write/edit/bash/grep slots and add an aft_ tool family on top. Installation is npx @cortexkit/aft@latest setup, which detects installed harnesses, writes their config, and resolves the binary via cache, npm platform package, PATH, cargo install, or GitHub release. Backups, indexes, and downloaded LSP servers live under ~/.local/share/cortexkit/aft/, and the project is MIT licensed.
Perception: aft_outline lists every symbol in a file, directory, or remote URL with kind, name, line range, visibility, and nested members; aft_zoom drills into one function or type and can annotate callers and callees with callgraph: true; aft_search runs hybrid semantic plus lexical retrieval over an index using local, OpenAI-compatible, or Ollama embedding backends; aft_callgraph follows callers, callees, data flow, and the shortest call path between symbols; aft_inspect returns one health report with LSP errors and warnings, TODOs, metrics, dead code, unused exports, and duplicates. Action: edit supports fuzzy find/replace, replacing a named symbol, batch and multi-file transactions, and glob replace; write creates directories, backs up, formats, and optionally returns inline diagnostics; apply_patch handles multi-file Begin Patch format with atomic rollback; aft_import adds, removes, and organizes imports per language; ast_grep_search and ast_grep_replace do structural matching with meta-variables. Runtime: bash rewrites commands (cat to read, grep to the grep tool) and compresses per-command output; background: true spawns detached tasks managed with bash_status, bash_kill, and bash_watch; PTY sessions are driven with bash_write and inspected via bash_status; aft_safety keeps a per-file undo stack, named checkpoints, and restore. grep/glob run on trigram indexes built in the background, persisted to disk, refreshed by a file watcher, and honoring .gitignore plus an optional .aftignore.
- Developers already on OpenCode or Pi whose agent burns tokens reading whole files, who want aft_outline and aft_zoom to fetch structure instead.
- TypeScript or frontend teams doing cross-file renames or import cleanup, replacing fragile line-based edits with symbol replacement and aft_import.
- Engineers dropped into a large unfamiliar repository who need aft_callgraph and aft_inspect to map call chains, dead code, and duplicated logic.
- People whose agent runs test suites, installers, docker ps, or kubectl and drowns in logs, using output compression plus background tasks and bash_watch.
- Users who need the agent to drive a REPL, vim, or a nested terminal, using PTY sessions through bash_write and bash_status.
- Teams that want a safety net around agent edits, relying on aft_safety's per-file undo stack and named checkpoints.
How do you install or deploy this agent?
Prerequisites: Node.js (for npx) and a target harness (OpenCode or Pi; OMP goes through the Pi plugin). Run the unified installer:
npx @cortexkit/aft@latest setupTarget a single harness if you prefer:
npx @cortexkit/aft@latest setup --harness opencode
npx @cortexkit/aft@latest setup --harness pi
npx @cortexkit/aft@latest setup --harness ompBuilding from source for development needs Bun ≥ 1.0 and Rust stable 1.92+:
bun install
cargo build --release
bun run buildHow do you use this agent?
On the next session start after setup, the aft binary downloads if needed and all tools come online. Configure at user or project level with aft.jsonc:
// ~/.config/cortexkit/aft.jsonc or <project>/.cortexkit/aft.jsonc
{
"enabled": true,
"inspect": {
"duplicates": {
"expected_mirrors": [["packages/opencode-plugin/**", "packages/pi-plugin/**"]]
}
}
}Diagnostics and cache management:
npx @cortexkit/aft@latest doctor
npx @cortexkit/aft@latest doctor --fix
npx @cortexkit/aft@latest doctor lspTo uninstall, first remove the harness registration: in OpenCode, delete the @cortexkit/aft-opencode entry from the top-level "plugin" array in ~/.config/opencode/opencode.jsonc; in Pi run:
pi remove npm:@cortexkit/aft-piWhat are this agent's strengths and limitations?
- It actually hoists the host's built-in tool slots (read, write, edit, bash, grep), so the agent keeps its normal call patterns while gaining tree-sitter parsing, indexed search, and output compression.
- One persistent Rust process per project root is shared across sessions, keeping parse trees warm while each session keeps an isolated undo history.
- Every mutation is parsed, formatted, and backed up before it hits disk, and aft_safety adds per-file undo stacks and named checkpoints for fine-grained rollback.
- Output compression targets noisy CLIs such as test runners, installers, docker ps, and kubectl, keeping errors and summaries while dropping the firehose.
- Broad language coverage: the README lists around 27 languages and calls out special handling for Metal, CUDA, Objective-C headers, and TOML.
- MIT licensed, published as a crate and npm packages, and not tied to one model vendor since semantic search can use local or Ollama embedding backends.
- Only three adapters exist today (OpenCode, Pi, and OMP via the Pi plugin); other hosts, MCP, and other frameworks are listed as future work.
- The benchmark suite is still in progress, so there are no published numbers for search latency, retrieval quality, token reduction, or end-to-end task success.
- Building from source requires Rust 1.92+ (pinned by the oxc 0.126 dependency family) with incremental compilation disabled by default, making first builds heavy.
- Coverage is uneven by language: Scala, Bash, HTML/Markdown, YAML, and TOML lack AST or import support, and Python refactoring is partial, missing cross-file moves.
- Semantic search needs an embedding backend choice; picking an OpenAI-compatible or remote backend means code snippets leave the machine.
- Contributions require an issue with the design-approved label before a PR is reviewed, which slows down drive-by fixes.
How does this agent compare with similar options?
Key facts side by side with the most closely related agents.
| Agent | Source review | Form / cost | Stars | Updated | Language | Full support on |
|---|---|---|---|---|---|---|
| AFT This agent | 58 · Major gaps | — | ★ 334 | 1d ago | Rust | — |
| CodeGraph | 44 · Major gaps | CLIFree + model costs | ★ 911 | 29d ago | Rust | Claude Code · OpenAI API · Claude API |
| Graphicle | 92 · Excellent | CLIFree + model costs | ★ 502 | 2d ago | Rust | Codex · Claude Code |
| GraphMind Code Graph | 64 · Some gaps | Desktop appFreemium | ★ 217 | 21d ago | Rust | Claude Code · Claude.ai |
How does FollowAgents rate this agent?
Why each dimension lost points
trust: least_privilege: config docs show sandbox, read_deny/write_allow, restrict_to_project_root, memory caps and systemd scope, with project tier only able to tighten (2); whether the sandbox is on by default and the default permission surface are not stated in the visible files, so not full marks. user_confirmation: only cache cleanup requiring the word delete or --yes and indirect host permission prompts are visible; no per-action confirmation for edits, writes, background tasks or PTY (1). data_flow_transparency: first bash reply lists applied env names and tiers, runon discloses what was not sent, semantic backends are named (2); embedding egress boundaries are thin. sensitive_data_handling: 0700/0600 storage, credential names refused at project tier, macOS privacy disclaim, credential-floor path normalization (2); no dedicated secret/token handling description. dependency_security: README pins oxc 0.126 requiring rustc 1.92 but there is no audit, SBOM or vulnerability response evidence (1). external_effects: background tasks, PTY, GitHub read/write and runon remote builds are described with some constraints (2) but no consolidated side-effect inventory. rollback: per-file undo stack, named checkpoints, atomic apply_patch rollback, pre-edit backups surviving restarts — well evidenced (3). source_attribution: MIT and CortexKit family are clear, but publisher identity is unverified with no signing or provenance proof (1).
self_consistency: README tool list, language matrix and architecture diagram broadly match docs/config.md key names; but README says benchmarks are "coming soon", docs/benchmarks.md marks numbers as undetermined, and investigations docs are based on different base commits, so version framing differs (2). dependency_availability: depends on Bun>=1.0, Rust 1.92+, crates.io/npm packages, optional LSP auto-download and embedding models; many install paths but no lockfile or offline-availability statement (1). failure_messages: config docs give many named errors (cache_dir_unavailable, cache_dir_config_unknown, privacy disclaim unavailable, list truncation footer), so failure messages are specific (2); but no unified semantics for tool-call failures.
audience_and_scenarios: clearly aimed at OpenCode/Pi/OMP coding agents with clear scenarios (symbol editing, semantic search, background tasks, PTY) (2); non-coding or unsupported-harness scenarios are not covered. capability_boundaries: language support matrix marks each item as check/partial/blank and states boundaries such as Objective-C headers, Metal syntax and TOML not in AST tools (2); but which tools are enabled by default and behavior when disabled are thinly described. trigger_precision: tool trigger conditions (when to use aft_search instead of grep, list truncation notices, bash rewrite rules) are documented (2); no quantified account of misfires or conflicts. environment_fit: covers Linux/macOS/Windows differences (cgroup, job object, footprint watcher, systemd scope, NFS storage override), with strong environment-fit evidence (2); Windows runtime unverified.
information_architecture: README sections are clear, docs/ splits tools/config/cli/benchmarks into files, investigations separated from design (2); some docs are internal investigation records mixed into the product doc tree. install_notes: npx setup auto-detects harness, uninstall steps listed per harness, dev build commands complete (2); no version compatibility matrix. naming_stability: config keys have retired-key translation and retained old names (worker_wait_max_ms), so naming evolution is explained (2); but tool names and config keys are numerous and stability commitments are unwritten. examples_and_faq: config and command examples exist but no FAQ, and examples concentrate on a few keys (1). known_limitations: explicitly lists Objective-C headers, Metal syntax, missing TOML AST, macOS memory sampling overshoot, unoptimized PTY state replay and unpublished benchmarks (2). license: MIT, consistent between README and badge (2). versioning_changelog: no CHANGELOG, only a setup example writing a fixed version number; versioning policy unstated (1). maintenance_responsibility: CONTRIBUTING has a design-approved process and Discord, but publisher is unverified and the responsible maintainer entity is unclear (1).
output_usability: tool output design considers usability (list truncation footer, compression preserving errors and summaries, structured outline/zoom) (2); actual output quality not verified by execution. marginal_value: versus native read/edit/bash, symbol-level editing, semantic search, call graphs and undo stack offer real incremental value (2); but similar capabilities already exist in the ecosystem and the increment is unquantified. cost_benefit: a resident Rust process per project, trigram/semantic indexes, LSP downloads and embedding models bring disk and memory cost; README claims token savings but benchmarks are "coming soon", so cost/benefit lacks evidence (1).
claim_traceability: most capability claims map to docs and code symbol references (investigations give test names and commands), but README performance and token-savings claims have no data support (1). cross_source_corroboration: README, config.md, design and investigations corroborate each other on sandbox, config tiers and background tasks (1); investigations are based on different base commits, limiting cross-source consistency. fact_inference_separation: docs clearly separate implemented, deferred (PTY replay), unmeasured and "coming soon", so inference and fact are well separated (2).
- Publisher identity is unverified; verify the npm/crates.io packages against the repository and check signatures before installing.
- setup rewrites host configuration and replaces built-in read/write/edit/bash tool slots — a high-impact change; validate in an isolated environment first.
- Whether the sandbox is enabled by default and how wide the default permission surface is are not clear from the visible docs; for sensitive repositories configure restrict_to_project_root and sandbox explicitly.
- Semantic search can use OpenAI-compatible or Ollama backends, so code snippets may leave the machine; confirm data-flow and compliance requirements.
- Benchmark and token-savings claims are unpublished; cost/benefit cannot be confirmed statically from source.
- Requires Rust 1.92+ and a pinned oxc version; no dependency audit or vulnerability-response evidence is visible.
Recent releases
Latest entries from the project's GitHub Releases. Notes are quoted from upstream as written, not rewritten or tested by FollowAgents.
-
Release notes excerpt
v0.63.5 AFT 0.63.5 fixes two problems introduced in 0.63.4. It has no other changes. Fixed - AFT starts again inside a Linux sandbox that does not let it read the disk root, such as nono with Landlock. 0.63.4 stopped at startup there ([#1245](https://github.com/cortexkit/aft/issues/1245)). - aft_inspect on two or more files outside the project no longer fails with "refused again after it was approved" after the first approval in OpenCode 2 daemon mode ([#1258](https://github.com/cortexkit/aft/issues/1258); thanks @iceteaSA).View on GitHub ↗ -
Release notes excerpt
v0.63.4 AFT 0.63.4 replaces 0.63.0 through 0.63.3, which were not published because their release builds failed. It adds shell memory limits, changed-file reports and a separate cache location. Diagnostics, call graphs, command recovery and permissions are fixed, with lower resource use. Upgrading - Outdated call graphs and symbol caches rebuild on use; call-graph caches take about three quarters less disk space. …View on GitHub ↗