Preload named GitHub identities in pod-based OpenAB sessions

[vixenclawsastraagent]

Summary

OpenAB pod-based ACP sessions need a supported way to preload and reuse named GitHub identities, so coding and review agents can use the correct GitHub account without running device-flow authentication in every new Discord thread/session.

This issue is scoped to OpenAB deployments where agents run inside pods or similarly isolated runtime containers. It is not a request to change OpenClaw host-machine behavior.

Motivation

Scott's OpenAB workflow uses different GitHub identities for coding and PR review. In particular, the review flow needs identities such as:

• vixenclawsastragent
• HsiehShuJeng

At least one identity, vixenclawsastragent, already appears to have an existing OpenAB-side mechanism in Scott's environment. The desired direction is to extend that mechanism so another identity, HsiehShuJeng, can also be preloaded and reused.

The problem is specific to OpenAB because OpenAB runs the ACP agent sessions inside pods. Each Discord thread effectively starts or uses a pod-local ACP session, so relying on the host machine's gh auth state is not enough.

OpenClaw does not have the same problem in Scott's current setup because the relevant sessions run on the host machine, where Scott can periodically authorize the needed GitHub identities and reuse the host's existing GitHub CLI state.

Expected Behavior / Desired Outcome

OpenAB should provide a documented credential lifecycle for named GitHub identities inside pod-based agent sessions.

Required behavior:

• WHEN OpenAB is about to create or bind an ACP session for a Discord thread, DO resolve and validate the selected GitHub identity before launching the agent subprocess, THEN do not let the agent discover missing auth interactively inside the newly created task thread.
• WHEN an OpenAB pod starts, DO make configured GitHub identities available to the agent runtime through documented environment variables, mounted files, or generated gh config, THEN ACP subprocesses can run gh auth status and Git operations without fresh device-flow login.
• WHEN a new Discord thread creates or resumes an ACP session, DO pass the selected GitHub identity context into the session, THEN the coding or review agent uses the intended account.
• WHEN the selected identity token is still valid, DO reuse it, THEN do not prompt Scott to authorize again.
• WHEN the selected identity token is expired, revoked, or missing required scopes, DO fail with an explicit reauthorization prompt naming the identity, THEN avoid falling back silently to the wrong GitHub account.
• WHEN Scott reauthorizes an expired identity, DO update the OpenAB credential source used by future pods/sessions, THEN new sessions can use the refreshed identity without per-thread setup.
• WHEN multiple identities are configured, DO keep them separated by logical identity name, THEN a review task can intentionally use a different GitHub identity from the PR author.

For Scott's current workflow, the minimum target identities are:

• vixenclawsastragent
• HsiehShuJeng

Scope and Constraints

• This is scoped to OpenAB pod/container environments. Do not require or redesign OpenClaw host-machine GitHub auth.
• The implementation must not print GitHub tokens in logs, Discord messages, test output, or generated diagnostics.
• Token storage source must be explicit. Acceptable sources may include Kubernetes Secrets, mounted secret files, or another documented deployment secret backend.
• The runtime must make clear which identity is active for a task. A coding/review automation flow should not accidentally review a PR using the author's GitHub identity.
• ACP session startup must not depend on the agent figuring out GitHub auth after the Discord thread has already been created and bound. Identity validation should happen before launch, or the session should fail early with a clear operator-facing reauthorization message.
• The system should support identity refresh as an operator action. It does not need to make GitHub tokens magically non-expiring.
• Existing single-token deployments should continue working unless they opt into named identities.

Possible config shape, for discussion:

[github_identities.vixenclawsastragent]
gh_config_dir = "/var/lib/openab/github-identities/vixenclawsastragent/gh"
git_config_global = "/var/lib/openab/github-identities/vixenclawsastragent/gitconfig"

[github_identities.HsiehShuJeng]
gh_config_dir = "/var/lib/openab/github-identities/HsiehShuJeng/gh"
git_config_global = "/var/lib/openab/github-identities/HsiehShuJeng/gitconfig"

Runtime implementation note:

• Named GitHub identities should be implemented as explicit runtime environment/profile selection before launching the ACP subprocess. At minimum this likely means setting GH_CONFIG_DIR, GIT_CONFIG_GLOBAL, and any Git credential helper or credential file paths for the child process according to the selected identity.
• GitHub CLI defaults should be documented: when GH_CONFIG_DIR is unset, gh uses $XDG_CONFIG_HOME/gh if set, otherwise $HOME/.config/gh on Linux. The identity-specific path above is therefore not a gh default; it only works when OpenAB explicitly exports GH_CONFIG_DIR for the selected child process.
• Avoid setting a global GITHUB_TOKEN or GH_TOKEN for all identities when named identity selection is enabled, because those environment variables take precedence over credentials stored in GH_CONFIG_DIR.

External dependency sources:

• GitHub credentials must come from an explicitly configured secret source, such as a Kubernetes Secret or mounted secret volume.
• The issue should document which component reads the secret, where the generated gh config lives inside the pod, and which env vars are passed to the ACP subprocess.
• Reauthorization should be an operator-visible flow that updates the secret or mounted credential source; the implementation must not require each new Discord thread to perform gh auth login.

Environment notes:

• [verified] The motivating OpenAB deployment is pod-based and each Discord thread maps to a thread/session workflow.
• [verified] Scott expects vixenclawsastragent and HsiehShuJeng to be usable identities.
• [verified] OpenClaw host-machine sessions are not the target for this issue.
• [assumed] Scott's current OpenAB deployment already has some mechanism for vixenclawsastragent; implementation should inspect and extend it rather than inventing a parallel one if possible.

Acceptance criteria:

• OpenAB documents how pod-based deployments configure named GitHub identities.
• OpenAB validates the selected GitHub identity before creating/binding an ACP task session that requires GitHub access.
• ACP subprocesses can select a named GitHub identity without per-thread device-flow login.
• vixenclawsastragent and HsiehShuJeng can be configured independently in Scott's OpenAB deployment.
• A newly created Discord task thread does not begin with the agent asking Scott to run gh auth login or search for credentials.
• Expired/revoked/missing-scope credentials produce a clear reauthorization prompt that names the affected identity.
• OpenAB does not silently fall back to another GitHub account when the requested identity is unavailable.
• Existing single-identity deployments continue to work.
• Validation or tests cover identity selection, missing identity, expired/invalid identity, and child-process environment propagation.
• Documentation states the credential source, pod path, env vars, refresh path, and security constraints.

---

Metadata (automation signals)

type: feature
regression: false
affected_area: "agent runtime / deployment credentials"
workaround_available: true
estimated_scope: medium

[vixenclawsastraagent]

Related infrastructure issue: #1516. The automated coding-to-review handoff should rely on the named GitHub identity support when reviewer identity selection needs to differ from the coding agent/PR author.

[chaodu-agent]

Cross-linking from #1516: the coding-to-review handoff there will be built on the Agent Control Plane adapter (agent-to-agent delegation), not the Discord adapter — see the rationale and status here: #1516 (comment)

This credential/identity work is a natural companion: CP's handoff needs the reviewer's GitHub identity to differ from the coding agent / PR author, which is exactly the named-identity preloading this issue tracks. Worth planning the two together in the CP context.

If you have suggestions, please bring them to our Discord too — happy to discuss: https://openab.dev/discord