fix(git): an agent with no repository stops filing a "could not check its git remotes" alert (#2930) - #2931
Merged
Conversation
… its git remotes" alert (#2930) The ent#615 sweep decided "could I see this tree?" with one flag, `root_readable`, set by `[ -d .git ] && [ -r ] && [ -x ]`. That fails on EXISTENCE as readily as on permissions, and an agent created from a `local:` template has no repository at all — so every stock starter (`acme-scout`/`sage`/`scribe`) filed an operator alert on every fresh install, and the alert told a first-time operator that the cause was `agent_full_capabilities=off` withholding DAC_OVERRIDE. On the instance this was found on, that setting was unset (defaults to true) and the container held DAC_OVERRIDE: the named cause was not the cause. The sweep now reports two more facts, and the caller splits them: * `root_traversable` — can this exec enter ROOT at all? The capability question, asked about ROOT rather than about the repo, because a missing DAC_OVERRIDE fails the `-d .git` test too and makes "absent" and "unreachable" identical. * `git_present` — is there a repository here? "Nothing to sweep" is not a finding. Traversable + absent → no alarm, one debug line. Everything else alarms exactly as before, so the ent#615 property is untouched: an all-zero report from a tree the sweep could not see is still never an all-clear. A report carrying neither flag parses both as 0 and routes to the alarm, which is the pre-#2930 behaviour. Tests: the real script against a repo-less directory, a real repo, and an unreadable one (positive controls on both flags), plus the four consumer shapes — absent, unreachable ROOT, present-but-unreadable, and an old flagless report. Fixes #2930 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
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
2 participants
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.
Summary
local:-template agent filed a "Trinity could not check this agent's git remotes" operator alert — three of them (acme-scout,acme-sage,acme-scribe) waiting on the Overview tab of a brand-new instance, each also lighting the yellow "1 item needs attention" banner.root_readablefails on existence as readily as on permissions, and those agents have no repository at all. The alert then blamedagent_full_capabilities=offwithholdingDAC_OVERRIDE; on the instance this was found on the setting was unset (defaults to true) and the container heldDAC_OVERRIDE, so a first-time operator was told to loosen a security setting that was never involved.Changes
The sweep script reports two more facts and
token_scrubsplits them:root_traversable— can this exec enterROOTat all? That is the capability question, and it is asked aboutROOTrather than about the repo on purpose: a missingDAC_OVERRIDEfails the-d .gittest too, which is what made "absent" and "unreachable" indistinguishable in the first place.git_present— is there a repository here?Traversable + absent → no alarm, one debug line. Every other shape alarms exactly as before, so the ent#615 property this must not trade away is intact: an all-zero report from a tree the sweep could not see is still never an all-clear. A report carrying neither flag parses both as
0and routes to the alarm — the pre-#2930 behaviour.Test Plan
pytest tests/unit/test_ent615_token_free_remotes.py— 96 pass (8 new)root_traversable=1,git_present=0), a real repo (both1), an unreadable one (root_traversable=0) — the two positive controls included, so neither assertion can pass against a hard-coded flagROOT→ alarm; present-but-unreadable → alarm; old flagless report → alarmNotes
Found while verifying #2899 on a fresh install. The sweep and its alert come from abilityai/trinity-enterprise#615 (PR #2757) — @AndriiPasternak31, worth your eyes since it is your area.
Fixes #2930
🤖 Generated with Claude Code