Repository context
Control primary commits, read-only supporting repositories, and manually approved context.
The primary repository is checked out at the exact commit associated with the workflow: a pull request head SHA, issue-planning base, or other recorded input snapshot.
Supporting repositories
A repository configuration can select up to 10 repositories from the same Tasuku organization as supporting context; the selection is repository-scoped and has no instance default. The agent starts with only the primary repository and a catalog of approved supporting repositories. It can load one at its exact pinned commit when the task needs that evidence; loaded repositories remain read-only.
Use supporting context for shared schemas, SDKs, architecture definitions, or related services the agent may need to understand. It is not a way for one task to edit several repositories.
Context suggestions and clusters
Tasuku can retain suggested relationships or learned context with source provenance. Suggestions never activate themselves. An administrator or super user must approve and enable them before they influence later agent work.
Boundaries
- The agent can change files only in the primary bounded workspace for implementation tasks.
- The worker rejects artifact paths outside that workspace.
- Supporting repositories load only on demand and remain read-only.
- Repository access tokens are short-lived and controlled by the trusted runtime, not supplied as agent environment variables.
Review context selections when repositories are renamed, transferred, removed from the GitHub installation, or contain sensitive material irrelevant to the workflow.