Summary
An agent's chat surface gets a persistent workspace — the repos.conf checkouts and the ox code index that repos.ts builds, kept warm across restarts on the agent's PVC. An agent's scheduled jobs (jobs[]) get an emptyDir.
So the surface doing the long-running, autonomous work has the least context, while the interactive surface has the most. A job body cannot use ox code search at all, and ox agent prime resolves against a bare directory instead of a real checkout.
Why a job can't just build its own
It isn't affordable. Measured on a large monorepo agent:
|
|
| checkout |
~440 MB |
ox code index |
~1.8 GB |
cold ox index code |
~10 minutes |
A typical scheduled lane runs on a budget of tens of minutes and spends most of it on the actual task, so a cold index does not fit — and re-cloning + re-indexing per tick would burn far more than the work itself. Meanwhile the Deployment beside it has already paid that cost and is maintaining the index incrementally.
Proposal
Let a job body mount the agent's own persistence claim, read-only.
jobs:
- slug: nightly
run:
workspace: read-only # sees the agent's checkouts + ox indexThe agent already pays for the volume; the job just reads it. No second copy, no cold start, no new storage class.
The wrinkle worth designing for: the chart's PVC is ReadWriteOnce, so the job pod has to land on the same node as the agent Deployment. RWO permits multiple pods per node, so pod affinity to the Deployment is enough — but that belongs in the chart rather than in every consumer's values file, and it needs a defined behaviour when the agent pod is absent or rescheduling (fail the job? run without the workspace and say so?).
Alternatives considered
|
Why not |
| A separate PVC per job |
Duplicates GBs per agent and still starts cold — the index is the expensive part, not the disk |
| RWX (e.g. EFS) for the shared volume |
New storage class, and a file-based search index on a network filesystem is a poor fit |
| Server-side only — accept that jobs never search code |
Workable for semantic search (ox query is API-backed and needs no local state), but ox code is a local index by design, so this drops code search from jobs permanently |
Related
There's a smaller adjacent bug this uncovered, worth its own fix: ox agent prime exits 1 with must be run from within a coding agent unless --agent <name> (or a recognised AGENT_ENV) is passed. A runner that shells out to prime without it gets 0 bytes and no error it distinguishes from "nothing to report", so the whole standing-context section is lost silently. Documenting the flag as required for non-interactive callers — or making the failure louder — would save the next person the same hunt.
Summary
An agent's chat surface gets a persistent workspace — the
repos.confcheckouts and theox codeindex thatrepos.tsbuilds, kept warm across restarts on the agent's PVC. An agent's scheduled jobs (jobs[]) get anemptyDir.So the surface doing the long-running, autonomous work has the least context, while the interactive surface has the most. A job body cannot use
ox code searchat all, andox agent primeresolves against a bare directory instead of a real checkout.Why a job can't just build its own
It isn't affordable. Measured on a large monorepo agent:
ox codeindexox index codeA typical scheduled lane runs on a budget of tens of minutes and spends most of it on the actual task, so a cold index does not fit — and re-cloning + re-indexing per tick would burn far more than the work itself. Meanwhile the Deployment beside it has already paid that cost and is maintaining the index incrementally.
Proposal
Let a job body mount the agent's own persistence claim, read-only.
The agent already pays for the volume; the job just reads it. No second copy, no cold start, no new storage class.
The wrinkle worth designing for: the chart's PVC is
ReadWriteOnce, so the job pod has to land on the same node as the agent Deployment. RWO permits multiple pods per node, so pod affinity to the Deployment is enough — but that belongs in the chart rather than in every consumer's values file, and it needs a defined behaviour when the agent pod is absent or rescheduling (fail the job? run without the workspace and say so?).Alternatives considered
ox queryis API-backed and needs no local state), butox codeis a local index by design, so this drops code search from jobs permanentlyRelated
There's a smaller adjacent bug this uncovered, worth its own fix:
ox agent primeexits 1 withmust be run from within a coding agentunless--agent <name>(or a recognisedAGENT_ENV) is passed. A runner that shells out to prime without it gets 0 bytes and no error it distinguishes from "nothing to report", so the whole standing-context section is lost silently. Documenting the flag as required for non-interactive callers — or making the failure louder — would save the next person the same hunt.