4866996. Each one says how it was decided: a read-only probe you can run yourself, or a source read at that commit. Nothing here is repeated from an older list without being checked.
Status at a glance
Domain triggers you cannot remove
Still live. Established from source at4866996.
The four base domain write commands do not agree on which tier they operate on. add-trigger resolves the workspace and writes {workspace}/.base/domains.toml. create, remove and remove-trigger ignore where you are standing entirely and only ever touch the global ~/.base-gbl/domains.toml.
So a trigger added inside a workspace cannot be removed from the command line. remove-trigger reports the domain is not found while base domain list keeps showing it, because reads merge both tiers and writes do not.
What to do. Hand-edit {workspace}/.base/domains.toml and delete the [[domain]] block, or the offending entry in its prompt_keywords or paths array. If you want a domain to stay manageable from the command line, create it with base domain create first, which puts it in the global tier where the remove commands can reach it.
This verdict is source-grounded rather than reproduced. Reproducing it needs a mutating command, and running one against live tiers to demonstrate a bug is not a trade worth making. The three write functions take the current directory as an argument and never read it;
add_trigger is the only one that resolves a workspace.An empty result outside a workspace
Still live. Reproduced with read-only commands on 0.13.2. Some commands fail loudly outside a registered workspace, and some quietly answer from the global tier alone. The inconsistency is the problem, because an empty answer from the wrong directory is indistinguishable from an empty graph.project list errors. recall returns “No results found.” and means nothing by it. base doctor reports the global tier only, and base commands list shows only globally-scoped commands.
What to do. Run base project list first when a result surprises you. If it errors, you are outside a workspace and every other command’s “empty” answer is suspect. Then cd into the right workspace, or run base scaffold to register the one you are in.
Hooks never show an error
By design, and still true. Established from source at4866996.
All five hook events fail open. Any internal error is written to stderr, and the process exits 0 with empty stdout, so a broken graph or a failed query never blocks your session.
The cost is that a broken hook looks exactly like a hook that had nothing to say, and your agent host will usually not show you hook stderr. Silent breakage can persist for a long time.
What to do. Do not infer failure from missing output. Instead:
hook-events.jsonl is the audit trail, with the event, whether it succeeded, and how many domains matched. base doctor is the one surface that deliberately does not stay quiet: it reports config files that exist but cannot be parsed, and exits nonzero.
There is no complete list of every place base swallows an error, and this page will not invent one. The design is the answer: assume any hook can fail silently, and use the four commands above rather than reasoning from what you did or did not see.
The update banner nagging on a current binary
Fixed. Established from source at4866996.
The banner used to compare the version recorded in manifest.toml against the latest release, never against the binary you were running. Swap the binary by hand and the manifest went stale and nagged forever, and the stale value blocked the check that would have corrected it.
Session start now reconciles the recorded version against the running binary’s own compiled-in version before anything reads the manifest, and drops the pending-update string when the version changes. It self-heals, and it handles a rollback the same way.
If you still see it on an older binary. Correct version under [components.base] and clear pending_update under [update_check] in ~/.base-gbl/manifest.toml by hand. That file is plain config rather than the graph, so editing it is fine. base --version is always the truth about what is running.
base commands import corrupting commands.toml
Fixed. Established from source at 4866996.
The importer used to write TOML by hand and escape only double quotes, so any rule containing a newline, tab or backslash produced a file that could not be parsed back. The loader then discarded the parse error and returned an empty command list, which is why “Imported 8 command(s)” and “No commands configured” could both be true in the same minute.
The writer now serializes through the TOML library and round-trips the output back before writing, and refuses outright when the existing file does not parse rather than appending onto damage. There is a regression test named for the issue that puts newlines, tabs, backslashes and a trailing quote through serialize, write and read.
base doctor also now reports a commands.toml it cannot parse and counts it against health.
Practical upshot. base commands import is safe. If star commands go quiet, run base doctor first; it will name a corrupt config instead of leaving you guessing.
The “AST graph not yet populated” nag
Fixed. Established from source at4866996.
The pre-tool-use hint used to hand-join the legacy {workspace}/.base/ast.ttl path, while maps are written to the {app}/.base-ast/ sidecar. For any workspace mapped after that migration the check could never pass, so the hint fired on every search command and base sync --ast never silenced it. Queries were fine throughout, which is exactly why the hint contradicted a populated base ast list.
The check now resolves the same way queries do, sidecar first and legacy second, so both satisfy it.
-g writing to the wrong tier
Fixed. Established from source at 4866996, which is the commit that fixed it.
--global swapped the working directory for ~/.base-gbl and then searched upward for the nearest .base/. Nothing creates ~/.base-gbl/.base at install time, so on a machine that had only run base install, the search climbed past the tier to the home directory and took <home>/.base instead, which is a workspace tier. Every -g command then reported success against the wrong graph.
It was not specific to one command or one platform. base learn -g escaped the same way as base graph apply-ops --global.
The global tier now resolves to its one fixed location directly and skips the search, because a tier with exactly one location cannot meaningfully be “not found”. The workspace tier keeps the walk, and keeps refusing when the walk finds nothing.
What to do. Update. If you ran -g commands on an earlier 0.13.x, check <home>/.base/graph.nq for entries you meant to be global.
hook-events.jsonl growing unbounded
Partly addressed. Established from source at 4866996.
Every hook invocation appends a line. Truncation exists, at 10MB, keeping the last 5000 lines, but it runs from the dashboard rather than from the hook writer, so a machine that never opens base dashboard has nothing trimming the file.
What to do. Check its size occasionally in each tier’s .base/, open the dashboard now and then, or truncate it yourself. Nothing depends on its history; it is a debugging trail, not state.
Next
Debugging injection
The tools these entries keep pointing at.
Updating
Getting onto the version these verdicts describe.