BugFix: Git author_name and author_email not being used

[ableinc]

Creating PRs, updating issues, adding comments, and all other git operations are not using bot's specified git.author_name and git.author_email. Everything is still appearing as me (ableinc).

[ableinc]

Plan

Make GitHub-facing operations act as the bot account (issue #15)

Give the daemon its own GitHub credential (github.token_env / github.token_file) and thread it through every gh and git subprocess, so PRs, comments, labels and reactions are attributed to the bot instead of the human who ran gh auth login.

Context

Issue #15 reports that PRs, issue updates and comments still appear as ableinc despite git.author_name / git.author_email being configured.

Tracing the code, the commit-identity half already works and is correctly wired:

• cmd/agent.go:178 copies cfg.Git.AuthorName/AuthorEmail into gitpkg.Manager.
• internal/git/workspace.go applies it three ways: -c user.name/user.email on CommitAll, applyIdentity() writing user.name/user.email into the shared clone's config (inherited by every worktree), and IdentityEnv() (GIT_AUTHOR_*/GIT_COMMITTER_*) passed into the Claude subprocess at internal/orchestrator/loop.go:708.

What does not work — and cannot, with the current design — is GitHub-level attribution. Who GitHub says opened a PR, wrote a comment, applied a label or added a reaction is decided entirely by the token behind gh, never by git config. internal/gh/gh.go shells out to gh with no environment of its own (Client.run leaves cmd.Env nil), so every mutation runs as whatever account did gh auth login on the host — the human owner. README.md:265 currently documents this as intended behaviour; issue #15 is the maintainer asking for it to stop being intended.

The fix is therefore a configurable GitHub token for the daemon, not a change to the git identity code. Same conclusion for pushes: git push authenticates through the gh auth git-credential helper (credentialArgs in internal/git/workspace.go), which also resolves the host account's token unless told otherwise.

Approach

1. Config: where the bot token comes from — internal/config/config.go

Add to GitHubConfig:

// TokenEnv names an environment variable holding the GitHub token the daemon
// should act as. TokenFile is a path to a file containing one. At most one may
// be set; empty means "use whatever `gh auth login` configured on this host".
TokenEnv  string `json:"token_env"`
TokenFile string `json:"token_file"`

Deliberately no literal token field. embedded.go compiles the repo-root config.json into the binary via go:embed (and make embed-ready copies config.example.json into place when it is missing), so a literal token in config.json would be baked into every build. If the reviewer wants paste-a-token convenience anyway, adding token is a two-line change — but it should come with a loud boot warning.

• expandPaths(): add &c.GitHub.TokenFile to the existing pointer loop (ExpandPath("") returns "", so an unset value stays unset).

• Validate(): reject both being set at once ("set at most one of github.token_env and github.token_file").

• New method, next to Owned/Excluded:

  // ResolveToken returns the GitHub token the daemon should act as, or "" when
  // none is configured (fall back to gh's own auth state).
  func (g GitHubConfig) ResolveToken() (string, error)

  Reads the env var or the file, strings.TrimSpacees the result, and returns a specific error when a configured source is empty/unreadable ("github.token_env %q is not set", "read github.token_file %s: %w"). Resolution failure must be a startup error, not a mid-run surprise.

Adding fields is backwards compatible even with dec.DisallowUnknownFields(); existing config files without the keys keep loading.

2. Thread the token into gh — internal/gh/gh.go

Add a Token string field to Client (leave New(bin, dryRun) alone so existing callers/tests keep compiling) and use it in the single choke point Client.run:

if c.Token != "" {
    cmd.Env = append(os.Environ(), "GH_TOKEN="+c.Token, "GITHUB_TOKEN="+c.Token)
}

Every read and every mutation already funnels through run/runJSON, so this one change covers Comment, EditLabels, ensureLabel, React, CreatePR, LinkPRToIssue, AuthStatus, CurrentLogin, and all gh api calls. Both variable names are set because gh prefers GH_TOKEN but sub-tools honour GITHUB_TOKEN.

3. Thread the token into git — internal/git/workspace.go

Add GHToken string to Manager and append the same two variables in Manager.run, where cmd.Env is already built explicitly alongside GIT_TERMINAL_PROMPT=0 / GIT_EDITOR=true. The gh auth git-credential helper installed by credentialArgs then resolves the bot token, so clone, fetch and push all authenticate as the bot. Extend the existing comment block on credentialArgs/run to say so.

4. Wire it up and keep it out of Claude's reach — cmd/agent.go

In run(f), right after config.Load:

ghToken, err := cfg.GitHub.ResolveToken()
if err != nil { return err }

Pass it to gh.New(...) (set .Token) and into the gitpkg.Manager literal next to GHBinary. Keep the token in a local variable — do not write it back into cfg, which is handed to server.New and served by /config.

Hardening: when a token is configured, append "GH_TOKEN=", "GITHUB_TOKEN=" (empty) to the env handed to Claude at internal/orchestrator/loop.go:708, so a token supplied via token_env (already in os.Environ, which internal/claude/runner.go:230 inherits) is not handed to a bypassPermissions agent run. This needs a small plumbing decision: either add Options.GitHubTokenConfigured bool to the orchestrator and build the slice at the call site, or add a ScrubEnv []string to claude.Options. The call site approach is smaller. Claude is already forbidden from git/GitHub mutation by the system prompt in internal/orchestrator/prompt.go; with an empty GH_TOKEN, gh falls back to hosts.yml for reads, i.e. today's behaviour.

5. Boot check surfaces the identity — cmd/agent.go bootCheck

After ghClient.AuthStatus, call ghClient.CurrentLogin(ctx) and include the answer in the existing log.Info("start-up checks passed", ...) line as github_login. This makes "am I acting as the bot or as myself?" answerable with coding-agent-loop --check, which is the only cheap way to confirm the fix took. Treat a failure as a warning, not a boot failure, unless a token was explicitly configured (a configured-but-invalid token should fail fast, with the message naming github.token_env/github.token_file).

6. Redact and document

• internal/server/server.go getConfig: TokenEnv/TokenFile are names/paths, not secrets, so they can be returned as-is; add a github_token_configured boolean next to the existing discord_webhook_set flag, and show it in internal/web/assets/app.js alongside the existing redaction note (~line 781).
• config.example.json: add "token_env": "", "token_file": "" under github.
• README.md: new keys in the config table; rewrite the last sentence of pipeline step 7 (~line 265) which currently states the PR is opened under the human's account; add a short "Running as a bot account" section covering: create the bot GitHub account, invite it as a collaborator (or org member) on the target repos, mint a token with repo + read:org (or a fine-grained PAT with Contents / Issues / Pull requests read-write plus Metadata read), write it to a chmod 600 file, point github.token_file at it, and set git.author_email to the bot's <id>+<login>@users.noreply.github.com so commits link to the bot's profile rather than showing an unlinked name. Add a troubleshooting row for "PRs still appear as me" → run --check and read github_login.

7. Tests

• internal/config/config_test.go: ResolveToken from env and from file (with ~ expansion and trailing-newline trimming), the mutual-exclusion validation error, and the error when a configured source is missing.
• internal/gh/gh_test.go: extend the existing stubGH helper so the stub also records $GH_TOKEN, then assert the token reaches the subprocess when Client.Token is set and that nothing is forced when it is not.
• internal/git/workspace_test.go: same idea using a stub git on a t.Setenv("PATH", ...) prefix, or — if that fights the existing real-git tests — assert only on the env-building helper after factoring it out of run.
• internal/orchestrator/loop_test.go: the fake runner already captures claude.Options; assert the scrub entries are present when a token is configured and absent otherwise.

Files touched

File	Change
internal/config/config.go	TokenEnv/TokenFile fields, ResolveToken(), validation, path expansion
internal/gh/gh.go	Client.Token, env injection in run
internal/git/workspace.go	Manager.GHToken, env injection in run
cmd/agent.go	resolve token, wire into gh.New/gitpkg.Manager, report login in bootCheck
internal/orchestrator/loop.go	scrub GH_TOKEN/GITHUB_TOKEN from the Claude subprocess env
internal/server/server.go, internal/web/assets/app.js	github_token_configured flag
config.example.json, README.md	new keys + "Running as a bot account" docs
internal/{config,gh,git,orchestrator}/*_test.go	tests above

Verification

1. make build && go test ./....
2. Without a token configured: coding-agent-loop --check still passes and logs github_login=<your login> — no behaviour change for existing installs.
3. With a bot PAT in ~/.agent-loop/gh-token and "token_file": "~/.agent-loop/gh-token": --check logs github_login=<bot login>.
4. End to end on a scratch repo the bot can write to: label an issue agent-ready, let one --once pass run, then confirm on GitHub that the PR author, the issue comment author, the label events and the reaction are all the bot, and that git log on the branch shows git.author_name <git.author_email>.
5. --once --no-mutate still performs no writes (the DryRun guards are untouched).
6. Negative check: point github.token_file at a missing path and confirm the daemon refuses to start with a message naming the key.

Risks and decisions for the reviewer

• The commit-identity code is not broken. If the maintainer's actual complaint includes commits showing as ableinc, the cause is almost certainly that git.author_email is an address attached to the human's GitHub account (GitHub links commits by author email). That is a config fix, which the README addition covers; there is no code defect to repair there.
• Migration caveat — existing agent PRs stop being watched. tickPRComments (internal/orchestrator/prcomments.go:161) searches PRs authored by CurrentLogin. After the switch that is the bot, so PRs opened earlier under the human account fall out of the watch set. Options: accept it (they get superseded as issues are re-run), or add an optional github.pr_comments.extra_authors list. Recommend accepting it and documenting it; flagging it here because it is a silent behaviour change.
• Welcome side effect. pendingMentions skips comments authored by the daemon's own login. Today that login is the maintainer, so the maintainer's own @coding-agent mentions are silently ignored. Once the daemon runs as the bot, those mentions start working — worth a README note so it does not read as a new bug.
• Token surface. A PAT with write access to your repos now lives on disk. token_file with mode 600 is the recommended shape; the systemd unit runs with ProtectHome=read-only, which still permits reads. The Claude-env scrub in step 4 is what keeps the token out of a bypassPermissions agent process; if the reviewer would rather Claude keep ambient gh access, drop that step and accept that a token_env-supplied token is visible to the agent.
• No literal token config key, per the go:embed reasoning above. Reversible if the reviewer disagrees.
• GitHub App instead of a PAT would give real app/coding-agent-loop[bot] attribution and short-lived tokens, but requires installation-token minting (JWT + refresh) inside the daemon. Out of scope here; the token plumbing added by this change is exactly what an App integration would later reuse.

---

Reply with exactly implement to approve this plan and start the change. Reply with anything else and the plan will be revised to address it.

_{coding-agent-loop run 52d4720d-4d6c-4ef6-ad4b-424e0c4b7741, model claude-opus-5, cost $1.7726}

[ableinc]

pull the latest main branch and revise your plan to ensure its up to date

[ableinc]

Plan

Make GitHub-facing operations act as the bot account (issue #15)

Give the daemon its own GitHub credential (github.token / token_env / token_file) and thread it through every gh and git subprocess, so PRs, comments, labels and reactions are attributed to the bot instead of the human who ran gh auth login.

What changed since the last plan

The working branch is at f203db5, which is byte-identical to origin/main and to ableinc/coding-agent-loop@main on GitHub (checked via gh api repos/ableinc/coding-agent-loop/commits/main). So this plan is written against current main; the two commits that landed after the previous draft are f47235b (config migration + --migrate-config + effort levels) and f203db5 (UI fixes + internal/install/nginx.conf). Three things in the previous plan need revising because of them:

1. internal/config/migrate.go now exists (Migrate, MigrateResult, diffKeys, driven by --migrate-config in cmd/agent.go:306). Any new config key must land cleanly in that path — it is now the supported way existing installs pick up new fields, and it round-trips the whole config through json.MarshalIndent, which matters for a secret-bearing field.
2. server.password (merged in Password lock UI #13) set a precedent for a plaintext secret in config.json — documented at README.md:489 as "stored in plaintext, so keep config.json readable only by the daemon user", and redacted in getConfig. The previous plan refused a literal github.token on go:embed grounds; that reasoning no longer holds up against the precedent, so the literal field is now included (details and escape hatch below).
3. Line anchors moved: the Claude env is built at internal/orchestrator/loop.go:709, getConfig is internal/server/server.go:426, the console's redaction note is internal/web/assets/app.js:865.

Everything else in the previous plan still holds and is repeated below in full.

Context

Issue #15 reports that PRs, issue updates and comments still appear as ableinc despite git.author_name / git.author_email being configured.

The commit-identity half already works and is correctly wired:

• cmd/agent.go:180 copies cfg.Git.AuthorName/AuthorEmail into gitpkg.Manager.
• internal/git/workspace.go applies it three ways: -c user.name/user.email on CommitAll (line 256), applyIdentity() writing user.name/user.email into the shared clone's config (inherited by every worktree), and IdentityEnv() (GIT_AUTHOR_*/GIT_COMMITTER_*) passed into the Claude subprocess at internal/orchestrator/loop.go:709.

What does not work — and cannot, with the current design — is GitHub-level attribution. Who GitHub says opened a PR, wrote a comment, applied a label or added a reaction is decided entirely by the token behind gh, never by git config. internal/gh/gh.go:67 (Client.run) shells out to gh leaving cmd.Env nil, so every mutation runs as whatever account did gh auth login on the host — the human owner. README.md:269 currently documents this as intended behaviour; issue #15 is the maintainer asking for it to stop being intended.

The fix is therefore a configurable GitHub token for the daemon, not a change to the git identity code. Same conclusion for pushes: git push authenticates through the gh auth git-credential helper installed by credentialArgs (internal/git/workspace.go:77), which also resolves the host account's token unless told otherwise.

Approach

1. Config: where the bot token comes from — internal/config/config.go

Add to GitHubConfig (line 59), next to Binary:

// Token is the GitHub token the daemon acts as. TokenEnv names an
// environment variable holding one; TokenFile is a path to a file
// containing one. Set at most one. All empty means "use whatever
// `gh auth login` configured on this host", i.e. pre-#15 behaviour.
Token     string `json:"token"`
TokenEnv  string `json:"token_env"`
TokenFile string `json:"token_file"`

• expandPaths() (line 300): add &c.GitHub.TokenFile to the pointer loop. ExpandPath("") returns "", so an unset value stays unset.

• Validate() (line 315): reject more than one of the three being set — "set at most one of github.token, github.token_env, github.token_file".

• New method next to Owned/Excluded:

  // ResolveToken returns the GitHub token the daemon should act as, or ""
  // when none is configured (fall back to gh's own auth state).
  func (g GitHubConfig) ResolveToken() (string, error)

  Returns Token as-is; otherwise reads the env var or the file and strings.TrimSpaces it. A configured-but-empty/unreadable source is an error (github.token_env %q is not set, read github.token_file %s: %w) so it fails at startup rather than mid-run.

Adding fields is backwards compatible for --migrate-config (they show up in Added) and forwards compatible for Load's DisallowUnknownFields (a file lacking them still loads onto Default()).

On the literal token field. embedded.go compiles the repo-root config.json into the binary, but that file is gitignored and make embed-ready copies config.example.json in when it is absent — so the tracked template can never carry a secret, and the only exposure is an operator's own locally-built binary containing their own token. That is exactly the posture server.password already has. Including it, with the same documented warning, is the consistent choice; token_file stays the recommended shape. If the reviewer disagrees, dropping Token is a two-line deletion plus one README row.

2. Thread the token into gh — internal/gh/gh.go

Add a Token string field to Client (leave New(bin, dryRun) alone so existing callers and tests keep compiling) and use it in the single choke point Client.run (line 67):

if c.Token != "" {
    cmd.Env = append(os.Environ(), "GH_TOKEN="+c.Token, "GITHUB_TOKEN="+c.Token)
}

Every read and every mutation funnels through run/runJSON, so this one change covers Comment, EditLabels, ensureLabel, React, CreatePR, LinkPRToIssue, AuthStatus, CurrentLogin and all gh api calls. Both names are set because gh prefers GH_TOKEN while sub-tools honour GITHUB_TOKEN.

3. Thread the token into git — internal/git/workspace.go

Add GHToken string to Manager and append the same two variables in Manager.run (line 87), where cmd.Env is already built explicitly alongside GIT_TERMINAL_PROMPT=0 / GIT_EDITOR=true. The gh auth git-credential helper then resolves the bot token, so clone, fetch and push all authenticate as the bot. Extend the credentialArgs comment block to say so.

4. Wire it up and keep it out of Claude's reach — cmd/agent.go

In run(f), right after config.Load (line 131):

ghToken, err := cfg.GitHub.ResolveToken()
if err != nil { return err }

Set it on the client built at line 156 and on the gitpkg.Manager literal at line 180 (next to GHBinary). Keep it in a local variable — do not write it back into cfg, which is handed to server.New and served by /config.

Hardening: a token supplied via token_env is already in os.Environ(), which internal/claude/runner.go:235 inherits, so a bypassPermissions agent run would otherwise hold the bot's write credential. Add ScrubEnv []string to claude.Options — variable names removed from the inherited environment when cmd.Env is built — and pass []string{"GH_TOKEN", "GITHUB_TOKEN"} from internal/orchestrator/loop.go:709 when a token is configured (plumbed as Options.ScrubGitHubToken bool on the orchestrator, set in cmd/agent.go). Removing the names beats setting them empty: gh then falls back to hosts.yml for reads with no ambiguity about how it treats an empty-but-set variable. Note runner.go:235 only assigns cmd.Env when len(opts.Env) > 0; the scrub must build cmd.Env regardless. Claude is already forbidden from git/GitHub mutation by internal/orchestrator/prompt.go, so this only closes the ambient-credential hole.

5. Boot check surfaces the identity — cmd/agent.go bootCheck

After ghClient.AuthStatus (line 404), call ghClient.CurrentLogin(ctx) and include the answer in the existing log.Info("start-up checks passed", ...) at line 435 as github_login. This makes "am I acting as the bot or as myself?" answerable with coding-agent-loop --check, the only cheap way to confirm the fix took. Treat a lookup failure as a warning — unless a token was explicitly configured, in which case fail fast with a message naming github.token/token_env/token_file.

6. Redact, migrate, document

• internal/server/server.go:426 getConfig: zero cfg.GitHub.Token before returning (same shape as cfg.Discord.WebhookURL and cfg.Server.Password above it) and add "github_token_set": tokenSet. TokenEnv/TokenFile are a variable name and a path, not secrets, and can be returned as-is.
• internal/web/assets/app.js:865: the redaction note currently names only the Discord webhook even though the password is redacted too. Rewrite it to cover all three, using cfgResp.github_token_set / password_set.
• --migrate-config: no code change needed — Migrate merges onto Default() and diffKeys reports github.token, github.token_env, github.token_file under Added. Worth a line in the README's "Migrating config.json" section (README.md:497) noting that migration round-trips a literal github.token through both the rewritten file and config.json.bak; both are written 0600 by migrateConfig (cmd/agent.go:334, :337), and *.bak is gitignored.
• config.example.json: add "token": "", "token_env": "", "token_file": "" under github.
• README.md: new rows in the config table after the github.pr_comments.* block (~line 458), carrying the same plaintext warning as server.password at line 489; rewrite the trailing clause of pipeline step 7 (lines 267–271), which currently states the PR is opened under the human's account; add a "Running as a bot account" section — create the bot GitHub account, invite it as a collaborator (or org member) on the target repos, mint a classic token with repo + read:org (or a fine-grained PAT with Contents / Issues / Pull requests read-write plus Metadata read), write it to a chmod 600 file, point github.token_file at it, and set git.author_email to the bot's <id>+<login>@users.noreply.github.com so commits link to the bot's profile instead of showing an unlinked name. Add a troubleshooting row (~line 896) for "PRs still appear as me" → run --check and read github_login.
• systemd (README.md:781–:800, internal/install/coding-agent-loop.service): the unit runs as the human user precisely because gh and Claude auth live in that home, and ProtectHome=read-only still permits reading a token file — so token_file works unchanged and is the recommended option under systemd. token_env would require systemctl edit to add an Environment=/EnvironmentFile= line; say so rather than adding a placeholder to the shipped unit template (a token does not belong in a world-readable unit file).

7. Tests

• internal/config/config_test.go: ResolveToken from literal, env and file (with ~ expansion and trailing-newline trimming); the mutual-exclusion validation error; the error when a configured source is missing. Follow the existing TestServerPasswordLoads / TestGitIdentityOverlaysFromConfig shape.
• internal/config/migrate_test.go: mirror TestMigrateReportsAddedFields (line 38) — an old config without the new keys reports github.token_file in Added.
• internal/gh/gh_test.go: extend stubGH (line 13) so the stub also records $GH_TOKEN/$GITHUB_TOKEN; assert the token reaches the subprocess when Client.Token is set, and that nothing is forced when it is not.
• internal/git/workspace_test.go: same idea with a stub git earlier on PATH via t.Setenv; if that fights the existing real-git tests, factor the env construction out of run into a helper and assert on that.
• internal/claude/runner_test.go: ScrubEnv removes a variable present in the parent environment.
• internal/orchestrator/loop_test.go: the fake runner already captures claude.Options; assert ScrubEnv is set when a token is configured and empty otherwise.
• internal/server/server_test.go:399: mirror the discord_webhook_set assertion for github_token_set, and assert the token is absent from the returned config body.

Files touched

File	Change
internal/config/config.go	Token/TokenEnv/TokenFile, ResolveToken(), validation, path expansion
internal/gh/gh.go	Client.Token, env injection in run
internal/git/workspace.go	Manager.GHToken, env injection in run
cmd/agent.go	resolve token, wire into gh.New/gitpkg.Manager, report github_login in bootCheck
internal/claude/runner.go, internal/orchestrator/loop.go	ScrubEnv for GH_TOKEN/GITHUB_TOKEN
internal/server/server.go, internal/web/assets/app.js	redact github.token, expose/show github_token_set
config.example.json, README.md	new keys, "Running as a bot account", migration + systemd notes
internal/{config,gh,git,claude,orchestrator,server}/*_test.go	tests above

Verification

1. make build && make test (the suite runs with -race; embed-ready handles the missing config.json in a fresh worktree).
2. Without a token configured: --check still passes and logs github_login=<your login> — no behaviour change for existing installs.
3. With a bot PAT in ~/.agent-loop/gh-token and "token_file": "~/.agent-loop/gh-token": --check logs github_login=<bot login>.
4. bin/coding-agent-loop --config <old-config> --migrate-config --dry-run on a pre-BugFix: Git author_name and author_email not being used #15 config: the three new keys are reported under "added at default" and the printed config still parses.
5. End to end on a scratch repo the bot can write to: label an issue agent-ready, run one --once pass, then confirm on GitHub that the PR author, the issue comment author, the label events and the reaction are all the bot, and that git log on the branch shows git.author_name <git.author_email>.
6. GET /config (and the console's Config tab) shows github.token empty with github_token_set: true.
7. --once --no-mutate still writes nothing (the DryRun guards are untouched).
8. Negative check: point github.token_file at a missing path and confirm the daemon refuses to start with a message naming the key.

Risks and decisions for the reviewer

• The commit-identity code is not broken. If the complaint includes commits showing as ableinc, the cause is almost certainly that git.author_email is an address attached to the human's GitHub account (GitHub links commits by author email). That is a config fix, covered by the README addition; no code defect to repair there.
• Migration caveat — existing agent PRs stop being watched. tickPRComments (internal/orchestrator/prcomments.go:261) searches PRs authored by CurrentLogin. After the switch that is the bot, so PRs opened earlier under the human account drop out of the watch set. Recommend accepting and documenting it rather than adding an extra_authors list; flagged because it is a silent behaviour change.
• Welcome side effect. pendingMentions (prcomments.go:106) skips comments authored by the daemon's own login. Today that login is the maintainer, so the maintainer's own @coding-agent mentions are silently ignored. Once the daemon runs as the bot they start working — worth a README note so it does not read as a new bug.
• Token surface. A PAT with write access now lives on disk. token_file with mode 600 is the recommended shape; the literal token field matches server.password's posture and inherits its caveats, including being copied into /opt/coding-agent-loop/config.json by --install and into config.json.bak by --migrate-config. The ScrubEnv step is what keeps it out of a bypassPermissions agent process; if the reviewer would rather Claude keep ambient gh access, drop that part of step 4 and accept the exposure.
• GitHub App instead of a PAT would give real app/coding-agent-loop[bot] attribution and short-lived tokens, but requires JWT-based installation-token minting and refresh inside the daemon. Out of scope; the plumbing added here is exactly what an App integration would reuse.

---

Reply with exactly implement to approve this plan and start the change. Reply with anything else and the plan will be revised to address it.

_{coding-agent-loop run 7a44b070-97ec-4ef5-b36f-819029439dea, model claude-opus-5, cost $1.6629}