Provision GitHub App identity and secret plumbing for fleet git hygiene

coilyco-ops commented

2026-07-09 18:04:00 +00:00

Member

Goal

Stand up the GitHub-side bot identity for ward and related automation so GitHub auth stops depending on Kai's personal login/token path.

Why

The current docs already point at the right model:

Forgejo automation uses the coilyco-ops bot token.
The GitHub lane in ward is designed to prefer a short-lived, repo-scoped GitHub App token over a PAT.
The token-minting docs in this repo already describe the App path and reject durable personal PATs as the fleet default.

What is still missing is the concrete provisioning / install / rotation path as a finished fleet primitive.

Scope

Register or confirm the GitHub App that will serve as the bot identity.
Install it on the intended repo set only.
Store the App ID + private key in SSM using the existing documented pattern.
Document the operational owner, rotation path, and least-privilege permissions.
Decide whether any legacy PAT-based GitHub automation should be retired once the App lane is live.

Decision to record

Define the policy explicitly:

GitHub automation defaults to GitHub App tokens.
Personal gh auth token is an attended-local fallback only.
Classic/fine-grained PATs are exceptional, not the fleet default.

Risks

Over-broad App installation scope.
Accidental fallback to personal credentials if the App path is only half-wired.
Repo permissions that are too narrow for PR-opening or too broad for routine use.

Dependency note

This is the upstream issue. ward cannot safely default its GitHub lane to bot-backed auth until this provisioning path is complete. The agentic-os-kai hygiene sweep can improve independently, but its final GitHub story depends on this landing first.

Filed by ward agent advisor cross-repo fan-out from coilysiren/inbox#171 (part 1 of 4, ward#424).

— Codex, via ward agent

## Goal Stand up the **GitHub-side bot identity** for `ward` and related automation so GitHub auth stops depending on Kai's personal login/token path. ## Why The current docs already point at the right model: - Forgejo automation uses the `coilyco-ops` bot token. - The GitHub lane in `ward` is designed to prefer a **short-lived, repo-scoped GitHub App token** over a PAT. - The token-minting docs in this repo already describe the App path and reject durable personal PATs as the fleet default. What is still missing is the concrete provisioning / install / rotation path as a finished fleet primitive. ## Scope - Register or confirm the GitHub App that will serve as the bot identity. - Install it on the intended repo set only. - Store the App ID + private key in SSM using the existing documented pattern. - Document the operational owner, rotation path, and least-privilege permissions. - Decide whether any legacy PAT-based GitHub automation should be retired once the App lane is live. ## Decision to record Define the policy explicitly: - GitHub automation defaults to **GitHub App tokens**. - Personal `gh auth token` is an attended-local fallback only. - Classic/fine-grained PATs are exceptional, not the fleet default. ## Risks - Over-broad App installation scope. - Accidental fallback to personal credentials if the App path is only half-wired. - Repo permissions that are too narrow for PR-opening or too broad for routine use. ## Dependency note This is the **upstream issue**. `ward` cannot safely default its GitHub lane to bot-backed auth until this provisioning path is complete. The `agentic-os-kai` hygiene sweep can improve independently, but its final GitHub story depends on this landing first. --- Filed by `ward agent advisor` cross-repo fan-out from coilysiren/inbox#171 (part 1 of 4, ward#424).  — Codex, via `ward agent`

coilyco-ops referenced this issue from coilyco-flight-deck/ward

2026-07-09 18:04:01 +00:00

Default GitHub-hosted agent runs to bot-backed auth and codify commit attribution #832

coilyco-ops changed title from ~~Provision GitHub bot identity and secret plumbing for fleet git hygiene~~ to Provision GitHub App identity and secret plumbing for fleet git hygiene

2026-07-09 18:04:51 +00:00

coilyco-ops commented

2026-07-09 18:04:52 +00:00

Author

Member

Terminology correction from Kai: the GitHub side is not a bot user. It is a GitHub App plus per-repo installation tokens. Forgejo has the coilyco-ops bot user. GitHub has an App identity whose short-lived installation tokens act for installed repos. The docs and command names should keep those models distinct.

Terminology correction from Kai: the GitHub side is not a bot user. It is a GitHub App plus per-repo installation tokens. Forgejo has the `coilyco-ops` bot user. GitHub has an App identity whose short-lived installation tokens act for installed repos. The docs and command names should keep those models distinct.

coilyco-ops commented

2026-07-09 18:05:13 +00:00

Author

Member

Specific-purpose docs filed as coilyco-flight-deck/infrastructure#492 so the provisioning issue does not blur the terminology: Forgejo bot user vs GitHub App installation identity.

coilyco-ops commented

2026-07-09 18:09:42 +00:00

Author

Member

Correction from Kai: the GitHub App auth is already configured. The likely gap is that the configuration is not mounted or surfaced into the runtime paths that need it. Also, model this as a multi-part GitHub App configuration, not as a single token like Forgejo. The current minting path documents app-id + private-key, but the operator-facing docs should also account for installation scope, permission configuration, and any App/client/webhook metadata needed by the specific GitHub flow. The implementation should first audit what is already in SSM/GitHub and then wire/mount the existing config, not assume a new GitHub identity must be created.

Correction from Kai: the GitHub App auth is already configured. The likely gap is that the configuration is not mounted or surfaced into the runtime paths that need it. Also, model this as a multi-part GitHub App configuration, not as a single token like Forgejo. The current minting path documents `app-id` + `private-key`, but the operator-facing docs should also account for installation scope, permission configuration, and any App/client/webhook metadata needed by the specific GitHub flow. The implementation should first audit what is already in SSM/GitHub and then wire/mount the existing config, not assume a new GitHub identity must be created.

coilyco-ops commented

2026-07-09 18:15:56 +00:00

Author

Member

WARD-RESERVATION: held 🔒

reservation details

Holder: container engineer-codex-infrastructure-491 on host kais-macbook-pro-2.local.

Reserved by ward agent --harness codex (reserved 2026-07-09T18:15:54Z). Concurrent ward agent runs are blocked until it finishes or the reservation goes stale (1h TTL). --force overrides.

Do not comment on or edit this issue to steer the run while it is reserved. The engineer seeded the body once at launch and never re-reads it, so a comment or edit reaches only human readers, never the running engineer. A correction goes to a new issue, dispatched fresh. That is the only channel that reaches a run in flight. Where the forge supports it, ward locks this conversation to make that a road-block rather than a convention (ward#494).

run seed context — what this run is carrying (ward#609)

Resolved: coilyco-flight-deck/infrastructure#491 · branch issue-491 · harness codex · workflow direct-to-main
Run: engineer-codex-infrastructure-491 · ward v0.493.0 · dispatched 2026-07-09T18:15:54Z
Comment thread: 3 included in the pre-flight read, 0 stripped (ward's own automated comments).
- included: @coilyco-ops (2026-07-09T18:04:52Z), @coilyco-ops (2026-07-09T18:05:13Z), @coilyco-ops (2026-07-09T18:09:42Z)

Static container doctrine and seed boilerplate are identical every run and omitted here (they ride ward v0.493.0).

— Codex, via ward agent

WARD-RESERVATION: held 🔒 <details><summary>reservation details</summary> Holder: container `engineer-codex-infrastructure-491` on host `kais-macbook-pro-2.local`. Reserved by `ward agent --harness codex` (reserved 2026-07-09T18:15:54Z). Concurrent `ward agent` runs are blocked until it finishes or the reservation goes stale (1h TTL). `--force` overrides. **Do not comment on or edit this issue to steer the run while it is reserved.** The engineer seeded the body once at launch and never re-reads it, so a comment or edit reaches only human readers, never the running engineer. A correction goes to a **new issue, dispatched fresh**. That is the only channel that reaches a run in flight. Where the forge supports it, ward locks this conversation to make that a road-block rather than a convention (ward#494). <details><summary>run seed context — what this run is carrying (ward#609)</summary> - **Resolved:** `coilyco-flight-deck/infrastructure#491` · branch `issue-491` · harness `codex` · workflow `direct-to-main` - **Run:** `engineer-codex-infrastructure-491` · ward `v0.493.0` · dispatched `2026-07-09T18:15:54Z` - **Comment thread:** 3 included in the pre-flight read, 0 stripped (ward's own automated comments). - included: @coilyco-ops (2026-07-09T18:04:52Z), @coilyco-ops (2026-07-09T18:05:13Z), @coilyco-ops (2026-07-09T18:09:42Z) Static container doctrine and seed boilerplate are identical every run and omitted here (they ride ward v0.493.0). </details> </details>  — Codex, via `ward agent`

coilyco-ops referenced this issue from a commit

2026-07-09 18:20:10 +00:00

docs: record GitHub App fleet hygiene plumbing

coilyco-ops closed this issue

2026-07-09 18:20:10 +00:00

coilyco-ops commented

2026-07-09 18:20:35 +00:00

Author

Member

WARD-OUTCOME: done ✅

details

workflow: direct-to-main; review summary: skipped (review gate skipped by ~/.ward/config.yaml default)
felt: straightforward doc wiring after tracing the existing minting path
confidence: high
surprises: remote main advanced during the push, so the branch had to be merged with origin/main before landing
follow-ups: none

WARD-OUTCOME: done ✅ <details><summary>details</summary> workflow: direct-to-main; review summary: skipped (review gate skipped by ~/.ward/config.yaml default) felt: straightforward doc wiring after tracing the existing minting path confidence: high surprises: remote main advanced during the push, so the branch had to be merged with origin/main before landing follow-ups: none </details>

Rows
Columns

Provision GitHub App identity and secret plumbing for fleet git hygiene #491

Goal

Why

Scope

Decision to record

Risks

Dependency note