owner/repository in the request still wins.
Working branch
By default daoco reads the repository’s default branch and opens pull requests against it. If your deployed content lives on a different branch, such as a release branch, choose it as the working branch on the connection card. daoco then reads files from that branch, creates new branches from it, and targets it with pull requests. A branch named in the request still wins. GitHub’s code search only covers the default branch. When a working branch is set, daoco lists directories on that branch instead of relying on search, so files that exist only there are still found. The working branch belongs to the default repository. Any other repository you name in a request uses its own GitHub default branch instead. Update the working branch whenever your release branch changes.Approval and access
Reads can run without approval. Every GitHub write requires approval in chat, even when the workspace uses an autonomous preset or automation. Approval applies to one named tool and its hash-bound input. Approving an issue write does not approve a merge, deletion, workflow run, or any later call. A code or content change is one write. daoco proposes it as a single pull request: the approval card shows the repository, the base branch, the new branch name, the pull request title, every file with its size, and the description. Approving it creates the branch, commits those exact files, and opens the pull request in one step, and daoco replies with the pull request link so a reviewer can merge it. Changing any of those details needs a new approval. One pull request carries at most 20 files; a larger change has to be split. The app can read repository metadata and contents, search code, and list issues and pull requests. It can create issues, branches, file commits, and pull requests only after daoco’s write-approval gate accepts that exact call. Changes made before disconnecting remain in GitHub. Disconnecting removes daoco’s access; it does not undo issues, branches, commits, pull requests, comments, or other completed actions.Content and article pull requests
daoco has an internal GitHub workflow for repository-backed content. It first reads comparable files to learn the repository’s directory, filename, front matter, image, and formatting conventions. It then proposes one pull request that carries the new branch, the full file contents, and the pull request title and description, and asks for a single approval. If a later step inside that write fails, daoco reports the branch and the files already committed instead of guessing whether GitHub applied the call or deleting anything automatically. Content that cannot be authored safely from repository evidence becomes an issue for a maintainer. This includes application code, shared templates, schema markup, redirects, build configuration, and changes that depend on product or engineering judgment.Permissions
The GitHub App requests repository metadata read access plus read and write access for contents, issues, and pull requests. GitHub limits each installation to the repositories selected during setup. daoco briefly exchanges GitHub’s user-authorization code to verify that the installer can access the installation, then discards that user token. Repository work always uses short-lived installation tokens; daoco does not store a personal access token or broad account OAuth token. An organization owner may need to approve the installation request. If GitHub records a request instead of an installation, daoco reports that state and does not create a connection until an owner approves it. If the card later says the connection is missing its installation details, choose Reconnect and run the install again.Connect GitHub
1
Open GitHub in Connections
Open Connections -> Integrations -> Work & Knowledge and choose GitHub.
2
Choose Connect
Choose Connect. GitHub opens its authorization page for the daoco App. Approve it. daoco uses that identity only to check which installations you can reach, then discards the token.
3
Choose an owner and repositories
If you have not installed the app yet, GitHub takes you to the installation page. Pick your personal account or an organization, then grant all repositories or select the repositories daoco should use. GitHub returns you to daoco automatically.
4
Set the default
Open the ⋯ menu on the connected GitHub card and choose Default repository. Pick the repository daoco should use when a request does not name one. If deployed content lives on a release branch, pick it as the working branch in the same dialog, then choose Save default.
5
Verify from chat
Ask daoco to read a file from the default repository.
Example requests
- “Read the existing articles in this repository, then open a PR for the approved draft.”
- “Open GitHub issues for the SEO findings that need engineering work.”
- “Review the open pull requests touching the marketing site.”