CodeAF: A Small, Careful First Experiment
A useful coding agent needs more than good answers. Something has to call the model, expose tools, retain task state, and make the resulting work reviewable. That surrounding machinery is the harness.
CodeAF is an early-preview harness worth a bounded experiment, not a migration. Do its task handoff and checking loop help with your work? Start with one disposable repository and an unambitious request. This is early triage, not an endorsement or an Aliz adoption recommendation.
What CodeAF Does
CodeAF is a Go-based terminal application, not a new model or an npm CLI. It connects model calls to file and shell tools, keeps conversations on disk, and coordinates task runs. Published binaries need no Go installation.
The useful distinction is between talking in a conversation and handing work to /task. A task starts or joins a background run with a plan store and a working copy. The harness has configurable worker, planner, and checker roles: execution, planning, and checking are separate responsibilities, not proof that the result is correct. The worker harness manual and crew configuration describe that structure.
Runs can continue independently of the terminal in the normal hosted workflow. Multiple overlapping tasks for the same folder can share a run and its working copy. Evaluate that handoff alongside your existing agent workflow.
Before Pointing It at a Repository
Interactive conversations without a saved approval choice default to YOLO, a permissive approval posture. A task working copy is not a security sandbox. Use a disposable environment and repository without production credentials, customer data, or other sensitive files.
The permissions manual explains the boundary. Check more than tracked files: task copies include uncommitted edits and untracked files. Inspect .codeaf/config.json before launching: repository settings can override personal settings.
Model calls cost money. Set a low provider-side spending limit before connecting, then use the application controls below as additional backstops—not a hard billing guarantee.
The example separately disables telemetry and Model Pool reporting. Those are independent controls; neither prevents prompts and tool results reaching your chosen model provider. See the telemetry disclosure. Treat credentials saved under CODEAF_HOME as secrets, too.
A Pinned First Run
This walkthrough was checked against upstream documentation and source. CodeAF was not installed or executed for this article; the snippets are not a successful-run transcript.
On macOS or Linux, have Bash, curl, and sha256sum or shasum available. We pin v0.7.0, released on 4 October 2026, more than a week before this post, and its installer source revision. This deliberately avoids a floating installer or “latest” release.
Use a fresh state directory; choose another path if this one already exists:
export CODEAF_HOME="$HOME/codeaf-lab-state"
export CODEAF_TELEMETRY=off
export CODEAF_MODEL_POOL=off
mkdir -p "$CODEAF_HOME"
curl -fsSL \
https://raw.githubusercontent.com/Agent-Field/CodeAF/19bac4ec78c10c4471235af9b0f05959c96a9405/scripts/install.sh \
-o "$CODEAF_HOME/install-v0.7.0.sh"
Open and review the downloaded script before continuing. Downloading it does not execute it. Check its download destinations, checksum verification, and filesystem changes against the pinned installer.
Only after that review:
VERSION=v0.7.0 bash "$CODEAF_HOME/install-v0.7.0.sh" \
--dir "$CODEAF_HOME/bin" \
--name codeaf-0.7.0 \
--no-modify-path \
--no-start
CODEAF="$CODEAF_HOME/bin/codeaf-0.7.0"
"$CODEAF" version
The installer verifies the binary against release checksums. These flags avoid PATH edits and automatic startup; the custom name keeps this experiment distinct. Pinning and checksums improve reproducibility, but are not a complete trust guarantee.
Choose a clean, non-sensitive repository with a README.md documenting its tests. Replace the placeholder path:
cd /absolute/path/to/a-disposable-repository
"$CODEAF" chat --no-host
--no-host keeps this conversation in-process rather than using the normal detached host, making lifecycle management easier for this experiment. First-run setup in this version offers OpenRouter browser sign-in or a pasted API key. Use the pinned getting-started instructions if setup differs; do not commit credentials.
Before sending work:
- Press Alt+A until the posture reads
asks. It cycles throughasks,guardian, andYOLO; one press is not guaranteed to selectasks. - Check
/statusand inspect/permissions. Do not assume omitting a--yoloflag makes the session cautious. - Set a small conversation budget and per-task cap:
/budget conversation 1
/crew cap task 1
These are $1 examples, adjustable to your experiment. Check the displayed confirmations and state before proceeding. The conversation budget implementation and limits documentation support these controls. If a cap is reached or accounting is unclear, stop rather than reflexively raising it.
Submit this as one line inside chat:
/task Read README.md and identify its documented test command. Do not edit files, run tests, install dependencies, push, or open a pull request. Report what you found and any uncertainty.
Those natural-language restrictions are instructions, not enforcement. Even this request creates local state and incurs provider usage.
Use /history to find the task, then open it and inspect activity, cost, and result. /status describes the conversation, not the task's full progress. Compare the reported command with the README yourself.
To end an active task, open its task room, type /stop, select stop it, and press Enter, as documented in the task controls. Verify it has stopped before quitting. Closing a normal hosted terminal can leave work running; do not substitute terminal closure for cancellation.
If the First Handoff Is Useful
For a second experiment, choose one bounded change or one intentionally failing test in another clean, disposable repository. State the acceptance criteria before handing it over. Review the diff independently and run the relevant tests yourself.
Tasks can commit work and automatically merge into eligible checkouts. Do not assume every result stays on an unmerged branch. A checker's verdict is evidence to inspect, not acceptance on your behalf.
Judge the workflow on observability, actual cost, review burden, and whether checking supplies useful evidence. Did you understand what ran and why? Could you stop it confidently? A disappointing answer is still a useful evaluation result.
Try a bounded experiment and share your impressions with fellow developers: setup surprises, observed cost, useful checks, and anything that made review harder. Describe what you actually observed, not what the project promises.