---
title: "GitHub-driven Agent Tasks"
description: "Bind repositories, configure Automation Rules and Agent Profiles, and safely trigger Workspace Tasks."
---

> Documentation Index
> Fetch the complete documentation index at: https://docs.appaloft.com/llms.txt
> Use this file to discover all available pages before exploring further.

# GitHub-driven Agent Tasks

## GitHub-driven Agent Tasks <a id="github-agent-tasks" />

GitHub is the trigger and feedback adapter. The business execution object remains an Agent Task,
and its isolated environment remains a Workspace/Sandbox. This capability does not create a second
Task, Preview, or Deployment model.

## Configuration order

1. Install the GitHub App and bind the numeric GitHub repository ID to an Appaloft Project.
2. Create an Agent Profile that references an installed Agent Adapter, Workspace Profile, Sandbox
   Template, and Credential Connection.
3. Create an Automation Rule with explicit event/action, actor policy, server pool, execution
   limits, Preview policy, and pull request delivery policy.

Label, `ready_for_review`, and `synchronize` rules pass the current Issue or pull request title and
body to the Agent as a bounded Task request instead of a context-free generic action. The request
is checked for length, environment assignments, and secret-like content before Workspace creation;
unsafe requests fail closed.

The CLI create and bind commands accept JSON input files containing non-sensitive references only.
Do not place API keys, environment variables, or raw credentials in these files.

```bash
appaloft github-agent repository bind repository-binding.json
appaloft github-agent profile create agent-profile.json
appaloft github-agent rule create automation-rule.json
```

## Security boundary

- Authorization keys use numeric GitHub IDs, never usernames.
- Fork pull requests, external collaborators, unlinked identities, insufficient permissions, and
  unavailable credentials fail closed.
- Rejection happens before Workspace creation or secret injection.
- Unattended rules use an explicit Project Automation Identity.
- Review runs execute at most once per repository, pull request, head SHA, and rule.

## Task control and feedback

Acknowledgements, status comments, and Check Runs use bounded updates. The same status comment and
Check Run are updated with check results, a redacted and bounded diff,
Preview access scope and TTL, pull request or Review delivery, and Workspace/Preview retention
state. Complete output remains on the Task page. Secret-like lines and URLs with sensitive query
parameters are never written to GitHub.

`steer` and `resume` retain the stable Task ID and append a new Run lineage. Native resume is
reported only when the installed adapter supports it and an opaque native session reference exists;
otherwise Appaloft reports the fallback and provides the previous summary, diff, check results, and
steering instruction to a new session.

```bash
appaloft workspace task stop <workspaceId> <taskRunId>
appaloft workspace task steer <workspaceId> <taskRunId> --instruction "keep the API compatible"
appaloft workspace task resume <workspaceId> <taskRunId>
```

Raw Credential Connection secrets are not exposed in GitHub comments, logs, database plaintext, or
test/Preview processes. `existing-server-config` requires an owner-scoped home directory.

Source: https://docs.appaloft.com/en/agents/github-agent-tasks/index.mdx