Retention settings control how long Coroid keeps the data your work produces. Find them under Settings → Data → Data retention.
What accumulates
Running work produces more than pull requests:
- task and execution history
- agent transcripts and tool call logs
- verification runs, check output and findings
- browser test artifacts
- notification and delivery history
- audit events
Most of it is operational — useful for weeks, rarely useful for years, and all of it is storage you are paying for and surface area you are responsible for.
Setting retention
Retention is configured per category, because the categories have genuinely different useful lifetimes. Execution transcripts are valuable while debugging a recent failure and rarely after. Audit events often have a mandated minimum.
Two forces set the window:
- How far back do we realistically look? For most operational data this is weeks.
- What are we required to keep? Audit and compliance obligations set floors you cannot go below.
Set retention to the longer of those, not to the longest value available.
Purging
When data passes its retention window it is purged. Purging is not reversible.
What purging does not touch:
- your repository, branches, commits or pull requests — those live with your provider
- project configuration, context and settings
- billing records
Purging removes Coroid's operational record of how work happened, not the work itself.
Deleted projects
Deleting a project removes its configuration and history from Coroid, and it is recoverable for a period before removal becomes permanent. That grace window is governed here.
Retention and audit
Audit events are usually the category with an externally imposed floor. If you export audit events to your own SIEM, your retention obligation can often be met there instead — which lets you keep a shorter window in Coroid while remaining compliant.
See Settings overview for where audit export is configured.