Agent sessions pay ~1s of pyenv on every git call, which is why aos-test takes 11 minutes #1004

Open
opened 2026-08-12 07:54:13 +00:00 by coilyco-ops · 4 comments
Member

Corrected. The original title and diagnosis of this issue were wrong. The suite is not inherently slow and macOS is not the cause. Both claims are kept below the fold so the correction is legible.

What is actually happening

One test, same machine, same commit, only PATH differs:

TestAOSComposeAliasesUseBothContextsWithoutWard
  with agent PATH     36.810s
  shim removed         2.786s

13x, from one PATH entry.

The entry is ~/.local/libexec/agent-git-attribution, prepended in agent sessions. Its git is a symlink to agent_git_attribution.py, whose shebang is #!/usr/bin/env python3. On this host python3 resolves to ~/.pyenv/shims/python3:

~/.pyenv/shims/python3      ~1030ms per start
/usr/bin/python3               32ms
/opt/homebrew/bin/python3      32ms

So every git call an agent makes spawns a pyenv shim that costs about a second before any Git work begins. exec.Command("git", ...) in the test helpers resolves through PATH, so the suite's hundreds of Git calls each pay it. That is the entire 645s.

The shim's own logic is not the problem. Its hot path for a non-commit command is find_real_git plus os.execv, which is cheap. Interpreter startup dominates.

Scope is much wider than this suite

This is not a test-suite issue. Every Git invocation in every agent session on this host pays roughly one second: every status, log, diff, add, commit, in every repository. The test suite is just where it became visible, because it makes hundreds of calls in a row.

Why CI never showed it

Not because Linux is faster at Git. CI has no attribution shim and no pyenv, so ci / aos-cli-tests runs the same tests in 4.462s (job 27640, log line 643). The 60x gap I reported earlier was this shim, not the platform.

The fix is not in this repo

Canonical source is ansible/roles/agent-git-attribution/files/agent_git_attribution.py in infrastructure, installed to {{ agent_git_attribution_script }} and symlinked as the shim git. Per the authoring-vs-rollout split, the change belongs there, not here.

Pinning the shebang away from the pyenv shim is the obvious candidate. Choosing the interpreter is a fleet decision (it has to exist on Linux hosts, macOS hosts, and the Windows convergence path), so I am not guessing at it here.

What stays true

#1003 is still correct and worth keeping. ward exec aos-test had no -timeout, so agents hit Go's 600s default against a 645-699s wall time and saw what looked like a hang. Once the shim is fixed the suite should land near 50s, and the raised timeout simply stops mattering rather than becoming wrong.

Retracted from the original version of this issue

  • Title "The aos-cli suite takes 11 minutes locally". It takes about 11 minutes in an agent session. In a plain shell it should be roughly 50s.
  • "That points at process-spawn and filesystem cost on macOS rather than at Git itself." Wrong. It is pyenv shim startup, invoked through the attribution shim.
  • "The Linux container is simply that much faster at the git-heavy native-shadow tests." Wrong, and it was inference stated too confidently. CI is fast because it has no shim.

The per-test timings in the original version remain accurate as a ranking, but every number in them is inflated by this shim.

**Corrected.** The original title and diagnosis of this issue were wrong. The suite is not inherently slow and macOS is not the cause. Both claims are kept below the fold so the correction is legible. ## What is actually happening One test, same machine, same commit, only PATH differs: ``` TestAOSComposeAliasesUseBothContextsWithoutWard with agent PATH 36.810s shim removed 2.786s ``` 13x, from one PATH entry. The entry is `~/.local/libexec/agent-git-attribution`, prepended in agent sessions. Its `git` is a symlink to `agent_git_attribution.py`, whose shebang is `#!/usr/bin/env python3`. On this host `python3` resolves to `~/.pyenv/shims/python3`: ``` ~/.pyenv/shims/python3 ~1030ms per start /usr/bin/python3 32ms /opt/homebrew/bin/python3 32ms ``` So every `git` call an agent makes spawns a pyenv shim that costs about a second before any Git work begins. `exec.Command("git", ...)` in the test helpers resolves through PATH, so the suite's hundreds of Git calls each pay it. That is the entire 645s. The shim's own logic is not the problem. Its hot path for a non-commit command is `find_real_git` plus `os.execv`, which is cheap. Interpreter startup dominates. ## Scope is much wider than this suite This is not a test-suite issue. Every Git invocation in every agent session on this host pays roughly one second: every `status`, `log`, `diff`, `add`, `commit`, in every repository. The test suite is just where it became visible, because it makes hundreds of calls in a row. ## Why CI never showed it Not because Linux is faster at Git. CI has no attribution shim and no pyenv, so `ci / aos-cli-tests` runs the same tests in 4.462s (job 27640, log line 643). The 60x gap I reported earlier was this shim, not the platform. ## The fix is not in this repo Canonical source is `ansible/roles/agent-git-attribution/files/agent_git_attribution.py` in **infrastructure**, installed to `{{ agent_git_attribution_script }}` and symlinked as the shim `git`. Per the authoring-vs-rollout split, the change belongs there, not here. Pinning the shebang away from the pyenv shim is the obvious candidate. Choosing the interpreter is a fleet decision (it has to exist on Linux hosts, macOS hosts, and the Windows convergence path), so I am not guessing at it here. ## What stays true #1003 is still correct and worth keeping. `ward exec aos-test` had no `-timeout`, so agents hit Go's 600s default against a 645-699s wall time and saw what looked like a hang. Once the shim is fixed the suite should land near 50s, and the raised timeout simply stops mattering rather than becoming wrong. ## Retracted from the original version of this issue * Title "The aos-cli suite takes 11 minutes locally". It takes about 11 minutes **in an agent session**. In a plain shell it should be roughly 50s. * "That points at process-spawn and filesystem cost on macOS rather than at Git itself." Wrong. It is pyenv shim startup, invoked through the attribution shim. * "The Linux container is simply that much faster at the git-heavy native-shadow tests." Wrong, and it was inference stated too confidently. CI is fast because it has no shim. The per-test timings in the original version remain accurate as a ranking, but every number in them is inflated by this shim.
coilyco-ops changed title from The aos-cli suite takes 11 minutes locally and 4 seconds in CI to Agent sessions pay ~1s of pyenv on every git call, which is why aos-test takes 11 minutes 2026-08-12 08:18:35 +00:00
Author
Member

Director support before this gets worked (#1177 phase 2). The fix this issue defers to infrastructure has already landed. What is left is convergence, not authoring.

The fleet decision is made

This issue says the interpreter choice is a fleet decision and declines to guess. Someone made it. In coilyco-flight-deck/infrastructure:

f977e8c  2026-08-13  perf(attribution): pin the Git shim interpreter off the pyenv shim

The canonical ansible/roles/agent-git-attribution/files/agent_git_attribution.py now opens:

#!/usr/bin/python3
"""Attribute agent-issued commits to the bot, Kai, and the active harness."""

# Pinned, not `env python3`: this is symlinked as `git`, so a pyenv shim on
# PATH costs 258ms against 67ms. The role asserts the path before installing.

Same diagnosis, same fix, and the role asserts the interpreter exists before installing, which is the Linux and Windows half the issue was right to worry about.

This host has not converged

The installed shim on the machine this lane is running on still carries the old shebang:

~/.local/libexec/agent-git-attribution/git
#!/usr/bin/env python3

So the 1s-per-git-call tax is still being paid here, thirteen days after the fix landed upstream. Every measurement in this issue still reproduces, and will keep reproducing until an ansible run converges the role on this host.

What that means for the lane

  • There is no engineering work in this repo for #1004. An engineer who picks it up and starts authoring a fix will write a second copy of one that already exists, in a repo the authoring-vs-rollout split says is not theirs.
  • The convergence run is an ops action on a live host, so it is not mine to take and not the headless lane's either. I am handing it to Kai rather than doing it.
  • The ordering stands. This stays first among the speed work for exactly the reason the lane gives: an 11-minute test cycle sets the iteration ceiling for the other 26 issues, and it is still 11 minutes on this host right now. It just resolves through a convergence run rather than a PR.

Suggested close path

  1. Converge agent-git-attribution on this host.
  2. Re-measure aos-test inside an agent session, not a plain shell, since the plain shell never had the shim on PATH.
  3. Close this against the measurement if it lands near the predicted 50s, or re-scope it to whatever survives.

#1003's raised timeout stays correct either way, exactly as this issue says.

**Director support before this gets worked (#1177 phase 2). The fix this issue defers to infrastructure has already landed. What is left is convergence, not authoring.** ## The fleet decision is made This issue says the interpreter choice is a fleet decision and declines to guess. Someone made it. In `coilyco-flight-deck/infrastructure`: ``` f977e8c 2026-08-13 perf(attribution): pin the Git shim interpreter off the pyenv shim ``` The canonical `ansible/roles/agent-git-attribution/files/agent_git_attribution.py` now opens: ```python #!/usr/bin/python3 """Attribute agent-issued commits to the bot, Kai, and the active harness.""" # Pinned, not `env python3`: this is symlinked as `git`, so a pyenv shim on # PATH costs 258ms against 67ms. The role asserts the path before installing. ``` Same diagnosis, same fix, and the role asserts the interpreter exists before installing, which is the Linux and Windows half the issue was right to worry about. ## This host has not converged The installed shim on the machine this lane is running on still carries the old shebang: ``` ~/.local/libexec/agent-git-attribution/git #!/usr/bin/env python3 ``` So the 1s-per-git-call tax is still being paid here, thirteen days after the fix landed upstream. Every measurement in this issue still reproduces, and will keep reproducing until an ansible run converges the role on this host. ## What that means for the lane * **There is no engineering work in this repo for #1004.** An engineer who picks it up and starts authoring a fix will write a second copy of one that already exists, in a repo the authoring-vs-rollout split says is not theirs. * **The convergence run is an ops action on a live host, so it is not mine to take and not the headless lane's either.** I am handing it to Kai rather than doing it. * **The ordering stands.** This stays first among the speed work for exactly the reason the lane gives: an 11-minute test cycle sets the iteration ceiling for the other 26 issues, and it is still 11 minutes on this host right now. It just resolves through a convergence run rather than a PR. ## Suggested close path 1. Converge `agent-git-attribution` on this host. 2. Re-measure `aos-test` inside an agent session, not a plain shell, since the plain shell never had the shim on PATH. 3. Close this against the measurement if it lands near the predicted 50s, or re-scope it to whatever survives. #1003's raised timeout stays correct either way, exactly as this issue says.
Author
Member

Kai is taking the convergence run. Recorded here so nobody in the lane duplicates it.

The role reaches this host as a dependency of claude-hooks and codex-hooks in ansible/playbooks/sync.yml, both unprivileged, so a local hooks-tagged sync applies it without touching privileged roles.

Engineer: leave #1004 alone until the shim is replaced. There is nothing to author. Once the run lands I will re-measure aos-test inside an agent session and close this against the number, or re-scope it to whatever survives.

**Kai is taking the convergence run.** Recorded here so nobody in the lane duplicates it. The role reaches this host as a dependency of `claude-hooks` and `codex-hooks` in `ansible/playbooks/sync.yml`, both unprivileged, so a local `hooks`-tagged sync applies it without touching privileged roles. Engineer: leave #1004 alone until the shim is replaced. There is nothing to author. Once the run lands I will re-measure `aos-test` inside an agent session and close this against the number, or re-scope it to whatever survives.
Author
Member

The authoring half of this is already done. What is left is convergence, which is not mine to run.

The fix landed a week after this issue

infrastructure@f977e8c ("perf(attribution): pin the Git shim interpreter off the pyenv shim", 2026-08-13) pinned the shebang to /usr/bin/python3, added the interpreter assert the diagnosis asked for, and closed infrastructure#823. It reports the same measurement this issue does, 258ms against 67ms on this host. The canonical file now reads:

#!/usr/bin/python3
"""Attribute agent-issued commits to the bot, Kai, and the active harness."""

# Pinned, not `env python3`: this is symlinked as `git`, so a pyenv shim on
# PATH costs 258ms against 67ms. The role asserts the path before installing.

The fleet-decision worry in the issue ("choosing the interpreter is a fleet decision") resolved cleanly: both inventory files already pin ansible_python_interpreter to /usr/bin/python3, so the role converges under the interpreter it now names.

This host has not converged

kais-macbook-pro still carries the pre-fix copy, so the cost is fully present today:

$ head -1 ~/.local/share/agent-git-attribution/agent_git_attribution.py
#!/usr/bin/env python3          # canonical says #!/usr/bin/python3

Measured just now, three runs each:

git --version  via the shim on PATH    0.27  0.22  0.22
git --version  direct                  0.00  0.00  0.00
python3        via ~/.pyenv/shims      0.20  0.22  0.25
python3        /usr/bin/python3        0.02  0.02  0.02

So ~220ms per Git call, and the pyenv shim is the whole of it. That is lower than the ~1030ms originally recorded, but the mechanism and the conclusion are unchanged: every status, log, diff, add, and commit in every agent session on this host pays it, and aos-test pays it hundreds of times.

The remaining action

Run the agent-git-attribution role against kais-macbook-pro, and check the other hands-on hosts for the same drift, since anything last converged before 2026-08-13 carries the old shebang.

Converging a live host is a DevOps action rather than an Engineer one, so I am handing it over rather than taking it. Leaving this issue open: the fix exists but its effect does not, and closing on the commit alone would record a speedup nobody has.

The authoring half of this is already done. What is left is convergence, which is not mine to run. ## The fix landed a week after this issue `infrastructure@f977e8c` ("perf(attribution): pin the Git shim interpreter off the pyenv shim", 2026-08-13) pinned the shebang to `/usr/bin/python3`, added the interpreter assert the diagnosis asked for, and closed infrastructure#823. It reports the same measurement this issue does, 258ms against 67ms on this host. The canonical file now reads: ```python #!/usr/bin/python3 """Attribute agent-issued commits to the bot, Kai, and the active harness.""" # Pinned, not `env python3`: this is symlinked as `git`, so a pyenv shim on # PATH costs 258ms against 67ms. The role asserts the path before installing. ``` The fleet-decision worry in the issue ("choosing the interpreter is a fleet decision") resolved cleanly: both inventory files already pin `ansible_python_interpreter` to `/usr/bin/python3`, so the role converges under the interpreter it now names. ## This host has not converged `kais-macbook-pro` still carries the pre-fix copy, so the cost is fully present today: ``` $ head -1 ~/.local/share/agent-git-attribution/agent_git_attribution.py #!/usr/bin/env python3 # canonical says #!/usr/bin/python3 ``` Measured just now, three runs each: ``` git --version via the shim on PATH 0.27 0.22 0.22 git --version direct 0.00 0.00 0.00 python3 via ~/.pyenv/shims 0.20 0.22 0.25 python3 /usr/bin/python3 0.02 0.02 0.02 ``` So ~220ms per Git call, and the pyenv shim is the whole of it. That is lower than the ~1030ms originally recorded, but the mechanism and the conclusion are unchanged: every `status`, `log`, `diff`, `add`, and `commit` in every agent session on this host pays it, and `aos-test` pays it hundreds of times. ## The remaining action Run the `agent-git-attribution` role against `kais-macbook-pro`, and check the other hands-on hosts for the same drift, since anything last converged before 2026-08-13 carries the old shebang. Converging a live host is a DevOps action rather than an Engineer one, so I am handing it over rather than taking it. Leaving this issue open: the fix exists but its effect does not, and closing on the commit alone would record a speedup nobody has.
Author
Member

The convergence ran. Measured on kais-macbook-pro just now, and the tax this issue is about is gone.

The installed shim carries the pinned interpreter:

$ head -1 ~/.local/libexec/agent-git-attribution/git
#!/usr/bin/python3          # was #!/usr/bin/env python3
$ head -1 ~/.local/share/agent-git-attribution/agent_git_attribution.py
#!/usr/bin/python3

Matching infrastructure@f977e8c exactly.

Per-call cost, ten calls each

through the shim on PATH   0.380s / 10  =  38.0 ms per call
/usr/bin/git directly      0.074s / 10  =   7.4 ms per call
                                           ------
shim overhead                              30.6 ms per call

Against the ~1030 ms this issue measured for a pyenv-shim start, that is roughly 3 percent of the former cost. The remaining 30 ms is interpreter start plus the shim's find_real_git and os.execv, which the issue already identified as the cheap part.

What I have not measured

I did not run aos-test. The native suite creates and removes worktrees and branches on this host, and there is a live engineer session working the lane, so running it is not mine to do while that is true.

The arithmetic is not the same as the measurement, and I would rather say so than present one as the other. The issue attributes the whole 645 s to hundreds of git calls each paying about a second. Those calls now pay 30 ms. Whether the suite lands near the predicted 50 s depends on what else is in it, and thirteen days of merges have been added since that number was taken.

Engineer: this is yours to close. Run just aos-test inside an agent session, not a plain shell, since a plain shell never had the shim on PATH and would have shown a fast number all along. Close against whatever it reports, or re-scope to whatever survives.

#1003's raised timeout stays correct either way, exactly as this issue says: once the suite is fast the timeout stops mattering rather than becoming wrong.

**The convergence ran. Measured on `kais-macbook-pro` just now, and the tax this issue is about is gone.** The installed shim carries the pinned interpreter: ``` $ head -1 ~/.local/libexec/agent-git-attribution/git #!/usr/bin/python3 # was #!/usr/bin/env python3 $ head -1 ~/.local/share/agent-git-attribution/agent_git_attribution.py #!/usr/bin/python3 ``` Matching `infrastructure@f977e8c` exactly. ## Per-call cost, ten calls each ``` through the shim on PATH 0.380s / 10 = 38.0 ms per call /usr/bin/git directly 0.074s / 10 = 7.4 ms per call ------ shim overhead 30.6 ms per call ``` Against the ~1030 ms this issue measured for a pyenv-shim start, that is **roughly 3 percent of the former cost**. The remaining 30 ms is interpreter start plus the shim's `find_real_git` and `os.execv`, which the issue already identified as the cheap part. ## What I have not measured I did not run `aos-test`. The native suite creates and removes worktrees and branches on this host, and there is a live engineer session working the lane, so running it is not mine to do while that is true. The arithmetic is not the same as the measurement, and I would rather say so than present one as the other. The issue attributes the whole 645 s to hundreds of git calls each paying about a second. Those calls now pay 30 ms. Whether the suite lands near the predicted 50 s depends on what else is in it, and thirteen days of merges have been added since that number was taken. **Engineer: this is yours to close.** Run `just aos-test` inside an agent session, not a plain shell, since a plain shell never had the shim on PATH and would have shown a fast number all along. Close against whatever it reports, or re-scope to whatever survives. #1003's raised timeout stays correct either way, exactly as this issue says: once the suite is fast the timeout stops mattering rather than becoming wrong.
Sign in to join this conversation.
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
coilyco-flight-deck/agentic-os#1004
No description provided.