Repository access

Connect a repository when the Task needs a working copy of code or files. Decide separately whether the result must be delivered through a pull request. Repository access, provider actions, and approval of the result are different decisions.

Repository context and pull-request delivery are separate

Every task has one repository picker. Choose No repository required, Project default, or an available repository. The choice and resolved source context are durable, so a later project or workspace default does not silently change existing work. Project default is always available, and choosing it again resolves the project's current setting.

The project separately decides whether repository-backed tasks require pull-request delivery. The Project setting applies to existing and future tasks, but becomes active only while a task has a repository. A task set to No repository required therefore uses ordinary completion review.

When the setting is off, an agent may still link a pull request as optional delivery evidence. There is no pull-request override on the task.

When an Agent discovers that a Task needs source context, it can request repository access. Task Machine checks the task's saved repository choice, blocks only that task, and sends one Repository needed decision to an eligible human in the Inbox. The human can choose an active workspace repository or create one there.

Repository-free work remains valid until the agent makes this explicit request, and task text never triggers it on its own.

Set repository defaults

A Project can supply repository defaults for new Tasks. A Task can explicitly use a repository or declare that one is not required. Existing work keeps its own context, so do not assume changing a Project default rewrites every Task already running.

Complete access and checkout

Add the repository's public key

When you create a repository, Task Machine prepares its repository SSH key and shows the public part to copy. Add that public key at your Git provider before expecting Cloud work to clone or push. Do not paste your personal private key into Chat or a Task.

Provider	Where to add the public key	Write access
GitHub	Repository Settings, then Deploy keys, then Add deploy key.	Enable Allow write access only when Agents need to push.
GitLab	Repository Settings, then Repository, then Deploy keys.	Enable Write access allowed only when Agents need to push.
Bitbucket	Repository settings, then Access keys.	Repository access keys are read-only. They can clone but cannot push branches.
Other Git hosts	The repository's SSH, deploy-key, or access-key administration.	Check the provider's supported scope and grant only what the work needs.

Give the key a recognizable title. Read-only access is appropriate when the Agent needs source context but should not push changes.

Recover from a checkout or access failure

A repository-access Inbox item keeps the public key, provider instructions, status, and retry action together. If the key is not ready, use Retry key setup. After adding the public key at the provider, return to Retry task or Retry chat in that same item.

A checkout failure may instead require correcting the clone URL or access. A retry that cannot be scheduled leaves the item open. Dismissing it does not repair the connection. See Setup and recovery.

Keep Local access and provider actions distinct

Cloud requires Task Machine's repository key. A Local Worker can use the offered repository key alongside the machine's existing SSH setup, or use existing local access when Task Machine has no repository key. A failed or unreachable key request is not treated as permission to fall back silently.

A working copy does not grant provider API capabilities such as pull-request actions. Configure the appropriate Connector and its credentials separately. Use Local execution when you deliberately choose to run on your own machine.

Preserve the delivery evidence

Review the exact pull-request revision and the checks that support it. Requested changes should return concrete feedback to the work. Approval can continue into delivery rather than immediately making every Task complete. Keep the Task's result and history as the durable record.

Read Pull requests and delivery when work must produce a reviewed code change.