bound agent-compose ps scheduler run scans

[winterfx]

Stacked on #88. This branch contains #88's three commits. Review only the last commit, c4aaf38. I will rebase onto main once #88 merges.

Summary

agent-compose ps was taking ~130s on a busy project, even with --limit 20. It now takes ~4s, and the Run associations are identical.

Root cause

ps labels each Sandbox with the Run that created it. When a listed Sandbox has no owning Run, it fetched every Scheduler Run in the project to find the one that created the Sandbox. The API gives no other way to do this: ListSchedulerRuns cannot filter by Sandbox, and Sandbox does not record its origin.

On a project with ~31.5k Scheduler Runs (~1.7k/day, 20-day retention), that is ~316 sequential requests. Each individual RPC is fast (0.1–0.5s).

Changes

Only the ps association path changes. listSchedulerRuns and the other commands are untouched.

• Look up only the listed Sandboxes. The lookup now covers just the Sandboxes being listed that no Run owns, instead of the project's whole history.

• Scan per agent first. A scheduler creates Sandboxes for its own agent, so each agent's Sandboxes are looked up with the agent_name filter. This skips high-volume polling agents, which made up 88% of the history here.

• Stop early. ListSchedulerRuns returns newest first (started_at DESC in the daemon store). The scan stops when either:

  • every wanted Sandbox is matched, or
  • runs started more than 24h before the oldest wanted Sandbox was created.

  The 24h margin covers a Scheduler Run that creates its Sandbox long after it starts, since common SCHEDULER_RUN_TIMEOUT values are a few hours.

• Fallback. Sandboxes still unmatched get the same bounded scan across all agents, so no association is lost if a scheduler ever creates a Sandbox for another agent.

• Unknown creation time. A Sandbox without created_at disables the cutoff and keeps the old exhaustive behavior.

No flags, config, environment variable, or .env changes.

Known limitation

Resolving a Scheduler Run from a short ID prefix still reads the full history. This affects inspect scheduler-run, scheduler logs, and scheduler stop, as well as an untyped inspect <ref> that does not match an earlier kind.

ResolveID has no Scheduler Run resource kind, so the CLI cannot do better. The proper fix is daemon-side: add a Scheduler Run kind to ResolveID, and a Sandbox origin field or a sandbox_id filter on ListSchedulerRuns. With those, ps would need no scan at all.

Test plan

• task fmt:check, task lint, task test
• New tests in ps_scan_test.go. The stub honors agent_name and counts requests. They cover:
  • stop once matched
  • stop at the cutoff
  • find a run inside the margin
  • exhaustive scan when created_at is unknown
  • no scan when Runs cover every Sandbox
  • per-agent scan skips a noisy agent
  • fallback when the agent differs
• Mutation-checked. Removing the matched stop, the cutoff stop, the per-agent scan, the fallback, or the unknown-time guard each fails at least one test.
• Live daemon, project with ~31.5k Scheduler Runs, ps --all --limit 100 (old vs new):
  • old: 131.9s
  • new: 4.4s
  • all 100 Sandboxes have the same Run association, none unassociated

🤖 Generated with Claude Code

[winterfx]

Folded into #88 so the agent-compose changes land as one PR. The commit (c4aaf38) is unchanged.