Bot account

By default every gh and git call junco makes runs under your ambient gh auth login — PRs, comments, labels, pushes, and commits all appear as you. botAccount.enabled routes daemon traffic through a dedicated machine account instead: a second, regular GitHub account (e.g. junco-agent), not a GitHub App. Off by default; behavior is unchanged until enabled.

Why

• Attribution. The daemon's traffic — start/run-once and everything downstream: the PR flow, worktree operations, the GitHub inbox/outbox/reporter — authenticates as the bot. Interactive commands stay on your personal login: dashboard actions, assess/analyze posting, submit, doctor's ambient probes. Worktree commits author as the bot via git config --worktree and its noreply email; your host git identity is never touched.
• Approval separation. The identity that dispatches work (the bot) and the identity that approves it (a human applying the approval label) are distinct. The approval check still verifies the human applier's write-plus permission — dispatcher and approver are no longer the same account. See the GitHub loop.

Setup

Create the machine account on github.com, then log it in with junco auth login: it runs gh's own device-flow login into an isolated GH_CONFIG_DIR (default ~/.junco/gh, separate from your own gh config; a legacy login at ~/.config/junco/gh keeps working until junco data migrate moves it), verifies the resulting identity, and flips botAccount.enabled to true on success. Nothing secret lands in config.json or the daemon's environment — gh owns token refresh, and the sandbox deny-lists the bot's config dir from agent reads (Security).

Grant repo access with junco auth grant: it invites the bot as you (admin on the repo required), accepts the invitation as the bot from its isolated config dir (bounded retry — invitation propagation can lag), then verifies the bot has push before reporting success. Idempotent — re-running on a granted repo is a no-op. Restart the daemon to apply the identity, and let junco doctor verify: it resolves the bot's identity (hard failure if not logged in) and checks its permission on each watched repo — write/maintain/admin passes; triage warns that label edits work but branch pushes fail; anything less warns to invite the bot. Repos you don't own need no invite at all — fork-PR mode provisions the fork on the bot's account.

junco auth login
junco auth grant acme/reef-api
junco restart
junco doctor

✓ junco-agent has write on acme/reef-api

Caveats

• SAML/SSO orgs. Grants fail with a SAML enforcement error regardless of identity. It is a one-time authorization, not a permission problem, and it happens in the bot's own browser session: sign in as the bot and authorize its gh OAuth token for the org. That click-through cannot be automated; auth grant and doctor recognize the error and print this guidance.
• Same-login bot. Logging the bot in under your own account defeats attribution and approval separation; doctor warns.
• One-time duplicates. Enabling the bot changes @me resolution for GitHub-side dedup, so a pre-existing thread may receive one duplicate plan comment or finding the first time it is touched. Documented behavior; it self-resolves — every subsequent dedup check runs consistently as the bot.
• Stale personal-fork remotes. External clones from before the bot was enabled have a fork remote pointing at your fork; the bot cannot push there and fails loud. Remove the stale fork remote and junco re-provisions a fork on the bot's account.