Repository navigation
feat(agent): let enable run outside an Atomic repository - #272
Merged
Merged
Conversation
graywolf336
approved these changes
Oct 16, 2026
graywolf336
approved these changes
Oct 16, 2026
Contributor
Author
|
Follow-up: removed the redundant Why: the integration packages (the normal enable path for every registry agent) install entirely into the home directory and never the repo. The pre-package Removed:
Net: 6 files, +72/−555. Marked Verified:
|
geekgonecrazy
force-pushed
the
fix/agent-enable-without-repo
branch
from
October 16, 2026 22:19
1892c61 to
806eaf9
Compare
graywolf336
approved these changes
Oct 16, 2026
`atomic agent enable` failed with RepositoryNotFound outside a repo, but nothing about hook installation needs one: every installed hook command is guarded by `test -d .atomic || test -f .atomic-sandbox && ...`, so hooks stay dormant until they fire inside an Atomic repository. Soften both `find_repository_root()?` calls in the enable path: - `run` now falls back to the current directory as the install base, with warnings that turns are only recorded in Atomic projects. - `.atomic/sessions/` is only created when `.atomic/` already exists, so enabling outside a repo never leaves a stray directory behind. - the `--agents-md` path in `install_integration` skips `[[repo-file]]` entries with a warning instead of failing the whole install (`InstallOptions.repo_root` was already optional). Inside a repository behavior is unchanged: same base directory, same sessions directory, no fallback warnings.
The previous fallback used the current directory as the install base, which wrote hooks into an arbitrary ./.claude/settings.json no agent session would ever read. Outside a repository the correct target is the home directory — the same one --global uses. - Rename repo_root → install_base in run(); outside a repo it is the home directory (via dirs::home_dir, an existing dependency). - Gate .atomic/sessions creation behind in_repo so the home .atomic/ (global config) is never touched by the fallback path. - Update the module and subcommand docs to match.
…where Every registry agent is packaged, and the packages install entirely into the home directory per their manifests (~/.claude/settings.json, ~/.config/opencode/opencode.json, skills, prompts) — never the repo. The repo root only feeds agent auto-detection, .atomic/sessions/, and --agents-md [[repo-file]] entries; the repo-relative AgentHook::install path is a degraded fallback for when the package cannot be fetched. State that plainly in the module and subcommand docs so the fallback is not mistaken for the primary behavior.
The integration packages (the normal enable path for every registry agent) install entirely into the home directory — ~/.claude/settings.json, ~/.config/opencode/opencode.json, skills, prompts — and never the repo. The pre-package `--global` path was a parallel, worse model: bare hooks only, no skills, no prompts, no receipt. With plain `enable` now falling back to the home directory outside a repository, there is one install model and `--global` only added confusion. - Remove the `--global` flag from `agent enable` and `agent disable`, along with both `run_global()` implementations. - `agent disable` gains the same outside-repo fallback (home directory) and always cleans both scopes — the uninstall base and the home config — so one command removes Atomic's hooks wherever they live, including legacy global installs that predate receipts. - Delete the now-orphaned install_global/uninstall_global methods and claude/gemini global_settings_path from atomic-agent; codex keeps global_hooks_path/is_installed_global, which its trait is_installed and the receipt-repair path still use. BREAKING CHANGE: `atomic agent enable --global` and `atomic agent disable --global` no longer exist; plain `enable`/ `disable` install and remove the same global hooks.
find_repository_root_from() walked up to filesystem root when run from /Users/bradleyhilton, skipping ~/.atomic (global config, no database) and returning a cryptic RepositoryNotFound. Stop at $HOME and surface a message pointing users to 'atomic init' or cd-ing into a real repository. Home is never treated as a valid repo root: .atomic/ still requires atomic.redb.
geekgonecrazy
force-pushed
the
fix/agent-enable-without-repo
branch
from
October 17, 2026 03:13
b09537f to
e5b45b9
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
atomic agent enableused to fail withRepositoryNotFoundoutside an Atomic repository. Nothing about enabling needs a repo, though: every installed hook command is guarded bytest -d .atomic || test -f .atomic-sandbox && ..., so hooks stay dormant until they fire inside an Atomic repository. This PR removes the requirement.What enabling actually does (and why the fallback targets home)
Every registry agent resolves to an integration package, and the packages install entirely into the home directory per their manifests —
~/.claude/settings.json,~/.config/opencode/opencode.json,~/.claude/skills/...,~/.config/opencode/plugins/atomic-hooks.ts, agent prompt slots — never the repo. The repo root only feeds:registry.detect, when no--agent).atomic/sessions/creation[[repo-file]]entries (e.g.AGENTS.md), and only with--agents-mdThe repo-relative
AgentHook::installpath inrun()is a degraded fallback for when the package cannot be fetched. This PR makes that fallback degrade to the home directory (where the packages install anyway) instead of failing:run—find_repository_root()?falls back to the home directory as the install base when no repo is found, printing warnings that turns are only recorded in projects with a.atomic/directory..atomic/sessions/— only created when a repo was found, so the fallback path never touches~/.atomic/(global config).--agents-md— the secondfind_repository_root()?(ininstall_integration, for[[repo-file]]entries) now skips those entries with a warning instead of failing the whole install.InstallOptions.repo_rootwas alreadyOption<PathBuf>, soNoneslots in cleanly.enable.rsandagent/mod.rsto state all of the above.Inside a repository, behavior is unchanged: same base directory, same sessions directory, no fallback warnings.
Verification
All e2e runs used a
HOMEoverride so the real~/.claude/settings.jsonwas untouched.cargo check -p atomic-cli— cleancommands::agenttests pass$HOME/.claude/settings.json, nothing in cwd, no.atomic/sessionsanywhereatomic initrepo: no fallback warnings,.atomic/sessions/created, 8 hooks in the repo's.claude/settings.json(via the built-in fallback — see note), nothing in$HOMENote
While testing I hit a pre-existing failure unrelated to this change: the claude-code integration package install exits non-zero ("partial install") because the cloned
atomic-skillsreleaseview is missingatomic-integration.tomlandAGENTS.mdat its root (they exist in the local checkout at~/code/work/atomic-skills, which is pushed, so the storagereleaseview looks stale). It reproduces identically inside and outside a repo, so it predates this PR — happy to dig into it separately.