Repositories
Configure repository automation, review signals, execute safety, protected paths, and ignore paths in Cloud Agents.
The Repositories tab is where Cloud Agents becomes safe and useful. Repository configuration determines which repositories are automated, what events trigger work, and where automation must stop.
Why Repository Configuration Matters
Without repository controls, parallel agent execution becomes expensive noise. With repository controls, Cloud Agents can review quickly, execute narrowly, and stop before it crosses boundaries your team did not approve.
Repository Readiness Checklist
Before a repository is marked ready for automation, check these conditions.
| Question | Why it matters |
|---|---|
| Does the repository have a clear branch and PR workflow? | Signals and run targeting only help when they map to a real engineering process. |
| Is validation already meaningful? | Validate after execute is only useful if the underlying checks are trusted. |
| Are code owners or approvers known? | Approval and policy without owners quickly becomes operational debt. |
| Are sensitive areas identifiable? | Protected paths should be explicit, not guessed run by run. |
| Are generated or noisy paths known? | Ignore paths are essential for keeping review signal quality high. |
Page Layout
The repository workspace is split into two parts:
- a Repository List that shows configured repositories and lets you switch context
- a Repository settings area that exposes automation defaults and safety settings for the selected repository
At the top of the page, summary cards usually surface:
| Card | What it summarizes |
|---|---|
| Configured | How many repositories are ready for automation |
| GitHub | Current connection state of GitHub access |
| Search | Matching repository entries in the current list |
| Safety | How many repositories have validation-after-execute or related protections enabled |
Who Should Own This Page
| Role | What they usually decide here |
|---|---|
| Repository owner or tech lead | Which automation behaviors are acceptable for this codebase |
| Platform or developer-experience team | Default patterns, rollout standards, and cross-repository consistency |
| Security or compliance reviewers | Which paths require stricter controls or approvals |
Repository List
Each repository card in the list tells you three things quickly:
- whether the repository is already configured or still needs attention
- which automation capabilities are enabled, such as Auto review, Auto execute, or PR signal
- whether the repository is currently selected or simply available to open
This turns the list into both an inventory and a policy summary.
Repository Settings Tabs
The selected repository exposes a settings surface organized into tabs such as Configuration, Signals, and Safety.
Configuration
Use Configuration for the default operating posture of the repository.
Common controls shown in the interface include:
| Control | Meaning | Most useful when |
|---|---|---|
| Auto review | Start review workflows automatically when configured signals arrive. | The team wants faster first-pass analysis on incoming change activity. |
| Auto execute | Allow agent-driven execution workflows for this repository. | The repository already has clear scope rules and the team is ready for controlled write-style automation. |
| Review on PR events | Start review runs from pull request activity. | Pull requests are the main review boundary in the repo. |
| Validate after execute | Run a post-execution validation pass before risky changes proceed. | The team wants execution outputs checked before they are trusted operationally. |
Recommended default for new repositories:
- enable Auto review
- keep Auto execute conservative until the repo policy is tested
- enable Review on PR events where the repo has active pull-request flow
- enable Validate after execute for any repository that matters operationally
Signals
Use Signals to decide which repository events should create or influence runs. The visible UI shows whether PR-related signals are part of the current automation posture. In practice this is where you make repository activity actionable instead of passive.
Safety
Use Safety to define where automation should not go and which paths should not consume review time.
Choosing a Policy Level
| Repository type | Recommended posture |
|---|---|
| Low-risk internal repo | Review automation on, execute narrow, approvals still available for sensitive outputs |
| Standard product repo | Review on PR events, execute conservative, validation on, protected paths defined |
| High-risk repo | Review-first only at the start, execute heavily constrained, protected paths broad, approvals expected |
Protected Paths
Protected paths are folders or files the repository marks as off-limits or approval-sensitive.
Good candidates include:
- infrastructure and workflow definitions
- authentication code
- billing or subscription code
- production migrations
- secret-handling utilities
Example patterns from the interface style:
src/app/**
infra/**
.github/workflows/**What protected paths achieve:
- prevent low-context execution across sensitive files
- force more deliberate review and approval behavior
- reduce the risk of an agent solving the wrong problem in the wrong place
Ignore Paths
Ignore paths tell Cloud Agents which directories create more noise than value.
Typical ignore targets:
- generated docs
- vendored dependencies
- build outputs
- lockstep generated SDK output
Example patterns from the interface style:
docs/**
public/vendor/**
dist/**Ignore paths are not a security feature. They are a signal-quality feature.
Coverage and Repository Health
The repository settings area can also show summary cards such as Coverage, Protected paths, and Ignore paths counts. These counts help answer whether a repository is truly governed or only superficially connected.
What good coverage looks like
Review allowed, execute controlled
The repository can review continuously, while execution is either manual or approval-gated until the team has confidence in the workflow.
Protected paths defined
Sensitive code areas are explicitly marked instead of relying on people to remember them in the moment.
Ignore paths trimmed
Generated or noisy directories are excluded so reviews stay focused on human-authored changes.
Recommended Repository Patterns
Monorepo
- use protected paths aggressively
- keep execute tasks scoped to one package or app at a time
- ignore generated directories per package
Product application repository
- enable PR-event review
- keep validation after execute on
- require approval for merge-capable outputs
Documentation repository
- create a custom docs-maintainer agent
- ignore generated build output
- allow broader review automation because the blast radius is lower
Common Repository Mistakes
- turning on Auto execute before protected paths exist
- using the same policy for a docs repository and a payments repository
- forgetting to ignore generated paths, then treating noisy findings as model failure
- leaving a repository configured with no clear owner for approvals or policy changes
- relying on defaults long after real run history has shown where the boundaries should be tighter
GitHub Dependency
Cloud Agents repository automation sits on top of the Console's GitHub integration rather than reimplementing it.
If a repository is missing, disconnected, or not syncing correctly, troubleshoot the connection with GitHub Integration first.
Related
Runs
Inspect the outputs produced by repository rules and signals.
Approvals
Use approvals to add human judgment on top of repository automation.
GitHub Integration
Complete the underlying repository authorization flow in the Console.
How is this guide?