fix(server): scope gh's child git processes to the selected account by enisze · Pull Request #9 · enisze/t3code

enisze · 2026-07-30T11:07:56Z

Problem

Per-project GitHub account pinning (#7) covers git push/fetch and the integrated terminal, but not the git processes gh itself spawns. GitHubCli.execute passed gitHubAccountGhEnv — token only, no credential config — so:

gh pr create pushing a branch with no upstream, and
gh pr checkout fetching

still fell back to the machine credential helper and acted as whichever account it had cached.

Fix

GitHubCli.execute now passes gitHubAccountAuthEnv, so gh's child git processes inherit the same credential config as our own git calls.
gitHubAccountAuthEnv appends its GIT_CONFIG_* pairs after any GIT_CONFIG_COUNT already in the parent env. Previously it hardcoded COUNT=2 and claimed indices 0/1, silently discarding an inherited runtime git config.
Silent fallback is now logged. A failed or empty gh auth token warns instead of quietly acting as the ambient account — that silence is what made the original bug hard to diagnose.
Tests for the path, which shipped without any: env shape (github.com + enterprise), inherited-config offset, malformed GIT_CONFIG_COUNT, gh child-process env, and terminal spawn env.
Drive-by:GitHubAccountResolver.test.ts was missing worktreeBranchPrefix after fix(server): restore access to existing worktrees #7 changed the contract, which broke tsgo --noEmit on main. Fixed.
Docs: the note in source-control-providers.md still said plain git pushes were unscoped. Replaced with what actually holds now, plus the two real limits (terminals pick up the account at spawn; SSH remotes can't be pinned).

Verification

Against two real gh accounts on one machine:

globally active: enisze
pinning to: ezsns
git would authenticate as: ezsns ✅
without the pin (pre-#7 behaviour):
username=15271433 ← stale OS keychain entry, neither account

tsgo --noEmit clean, 259 tests pass across sourceControl/vcs/terminal, lint clean. Targeted checks only, per AGENTS.md — CI owns the full suite. Not exercised through the UI.

🤖 Generated with Claude Code

Per-project GitHub account pinning covered `git push`/`fetch` and the integrated terminal, but not the `git` processes `gh` itself spawns: `gh pr create` pushing a branch with no upstream, and `gh pr checkout` fetching, still fell back to the machine credential helper and acted as whichever account it had cached. `GitHubCli.execute` now passes the full auth env instead of the `gh`-only one. Also hardens the env itself: the `GIT_CONFIG_*` pairs are appended after any `GIT_CONFIG_COUNT` already in the parent environment, so an inherited runtime git config is no longer silently overwritten by our pairs claiming indices 0 and 1. A failed or empty `gh auth token` now logs a warning rather than falling back to the ambient account in silence. Adds the tests this path was missing (env shape, inherited-config offset, gh child-process env, terminal spawn env), fixes a `worktreeBranchPrefix` fixture that broke typecheck, and updates the docs note that still claimed plain git pushes were unscoped. Verified against two real gh accounts: with the pin, git authenticates as the selected account while a different one is globally active; without it, git resolves a stale OS keychain entry. Claude Opus 5 (1M context) via Claude Code

enisze · 2026-07-30T11:07:56Z

Problem

Per-project GitHub account pinning (#7) covers git push/fetch and the integrated terminal, but not the git processes gh itself spawns. GitHubCli.execute passed gitHubAccountGhEnv — token only, no credential config — so:

gh pr create pushing a branch with no upstream, and
gh pr checkout fetching

still fell back to the machine credential helper and acted as whichever account it had cached.

Fix

GitHubCli.execute now passes gitHubAccountAuthEnv, so gh's child git processes inherit the same credential config as our own git calls.
gitHubAccountAuthEnv appends its GIT_CONFIG_* pairs after any GIT_CONFIG_COUNT already in the parent env. Previously it hardcoded COUNT=2 and claimed indices 0/1, silently discarding an inherited runtime git config.
Silent fallback is now logged. A failed or empty gh auth token warns instead of quietly acting as the ambient account — that silence is what made the original bug hard to diagnose.
Tests for the path, which shipped without any: env shape (github.com + enterprise), inherited-config offset, malformed GIT_CONFIG_COUNT, gh child-process env, and terminal spawn env.
Drive-by:GitHubAccountResolver.test.ts was missing worktreeBranchPrefix after fix(server): restore access to existing worktrees #7 changed the contract, which broke tsgo --noEmit on main. Fixed.
Docs: the note in source-control-providers.md still said plain git pushes were unscoped. Replaced with what actually holds now, plus the two real limits (terminals pick up the account at spawn; SSH remotes can't be pinned).

Verification

Against two real gh accounts on one machine:

globally active: enisze
pinning to: ezsns
git would authenticate as: ezsns ✅
without the pin (pre-#7 behaviour):
username=15271433 ← stale OS keychain entry, neither account

tsgo --noEmit clean, 259 tests pass across sourceControl/vcs/terminal, lint clean. Targeted checks only, per AGENTS.md — CI owns the full suite. Not exercised through the UI.

🤖 Generated with Claude Code

Per-project GitHub account pinning covered `git push`/`fetch` and the integrated terminal, but not the `git` processes `gh` itself spawns: `gh pr create` pushing a branch with no upstream, and `gh pr checkout` fetching, still fell back to the machine credential helper and acted as whichever account it had cached. `GitHubCli.execute` now passes the full auth env instead of the `gh`-only one. Also hardens the env itself: the `GIT_CONFIG_*` pairs are appended after any `GIT_CONFIG_COUNT` already in the parent environment, so an inherited runtime git config is no longer silently overwritten by our pairs claiming indices 0 and 1. A failed or empty `gh auth token` now logs a warning rather than falling back to the ambient account in silence. Adds the tests this path was missing (env shape, inherited-config offset, gh child-process env, terminal spawn env), fixes a `worktreeBranchPrefix` fixture that broke typecheck, and updates the docs note that still claimed plain git pushes were unscoped. Verified against two real gh accounts: with the pin, git authenticates as the selected account while a different one is globally active; without it, git resolves a stale OS keychain entry. Claude Opus 5 (1M context) via Claude Code

enisze · 2026-07-30T11:07:56Z

Problem

Per-project GitHub account pinning (#7) covers git push/fetch and the integrated terminal, but not the git processes gh itself spawns. GitHubCli.execute passed gitHubAccountGhEnv — token only, no credential config — so:

gh pr create pushing a branch with no upstream, and
gh pr checkout fetching

still fell back to the machine credential helper and acted as whichever account it had cached.

Fix

GitHubCli.execute now passes gitHubAccountAuthEnv, so gh's child git processes inherit the same credential config as our own git calls.
gitHubAccountAuthEnv appends its GIT_CONFIG_* pairs after any GIT_CONFIG_COUNT already in the parent env. Previously it hardcoded COUNT=2 and claimed indices 0/1, silently discarding an inherited runtime git config.
Silent fallback is now logged. A failed or empty gh auth token warns instead of quietly acting as the ambient account — that silence is what made the original bug hard to diagnose.
Tests for the path, which shipped without any: env shape (github.com + enterprise), inherited-config offset, malformed GIT_CONFIG_COUNT, gh child-process env, and terminal spawn env.
Drive-by:GitHubAccountResolver.test.ts was missing worktreeBranchPrefix after fix(server): restore access to existing worktrees #7 changed the contract, which broke tsgo --noEmit on main. Fixed.
Docs: the note in source-control-providers.md still said plain git pushes were unscoped. Replaced with what actually holds now, plus the two real limits (terminals pick up the account at spawn; SSH remotes can't be pinned).

Verification

Against two real gh accounts on one machine:

globally active: enisze
pinning to: ezsns
git would authenticate as: ezsns ✅
without the pin (pre-#7 behaviour):
username=15271433 ← stale OS keychain entry, neither account

tsgo --noEmit clean, 259 tests pass across sourceControl/vcs/terminal, lint clean. Targeted checks only, per AGENTS.md — CI owns the full suite. Not exercised through the UI.

🤖 Generated with Claude Code

Per-project GitHub account pinning covered `git push`/`fetch` and the integrated terminal, but not the `git` processes `gh` itself spawns: `gh pr create` pushing a branch with no upstream, and `gh pr checkout` fetching, still fell back to the machine credential helper and acted as whichever account it had cached. `GitHubCli.execute` now passes the full auth env instead of the `gh`-only one. Also hardens the env itself: the `GIT_CONFIG_*` pairs are appended after any `GIT_CONFIG_COUNT` already in the parent environment, so an inherited runtime git config is no longer silently overwritten by our pairs claiming indices 0 and 1. A failed or empty `gh auth token` now logs a warning rather than falling back to the ambient account in silence. Adds the tests this path was missing (env shape, inherited-config offset, gh child-process env, terminal spawn env), fixes a `worktreeBranchPrefix` fixture that broke typecheck, and updates the docs note that still claimed plain git pushes were unscoped. Verified against two real gh accounts: with the pin, git authenticates as the selected account while a different one is globally active; without it, git resolves a stale OS keychain entry. Claude Opus 5 (1M context) via Claude Code

enisze · 2026-07-30T11:07:56Z

Problem

Per-project GitHub account pinning (#7) covers git push/fetch and the integrated terminal, but not the git processes gh itself spawns. GitHubCli.execute passed gitHubAccountGhEnv — token only, no credential config — so:

gh pr create pushing a branch with no upstream, and
gh pr checkout fetching

still fell back to the machine credential helper and acted as whichever account it had cached.

Fix

GitHubCli.execute now passes gitHubAccountAuthEnv, so gh's child git processes inherit the same credential config as our own git calls.
gitHubAccountAuthEnv appends its GIT_CONFIG_* pairs after any GIT_CONFIG_COUNT already in the parent env. Previously it hardcoded COUNT=2 and claimed indices 0/1, silently discarding an inherited runtime git config.
Silent fallback is now logged. A failed or empty gh auth token warns instead of quietly acting as the ambient account — that silence is what made the original bug hard to diagnose.
Tests for the path, which shipped without any: env shape (github.com + enterprise), inherited-config offset, malformed GIT_CONFIG_COUNT, gh child-process env, and terminal spawn env.
Drive-by:GitHubAccountResolver.test.ts was missing worktreeBranchPrefix after fix(server): restore access to existing worktrees #7 changed the contract, which broke tsgo --noEmit on main. Fixed.
Docs: the note in source-control-providers.md still said plain git pushes were unscoped. Replaced with what actually holds now, plus the two real limits (terminals pick up the account at spawn; SSH remotes can't be pinned).

Verification

Against two real gh accounts on one machine:

globally active: enisze
pinning to: ezsns
git would authenticate as: ezsns ✅
without the pin (pre-#7 behaviour):
username=15271433 ← stale OS keychain entry, neither account

tsgo --noEmit clean, 259 tests pass across sourceControl/vcs/terminal, lint clean. Targeted checks only, per AGENTS.md — CI owns the full suite. Not exercised through the UI.

🤖 Generated with Claude Code

Per-project GitHub account pinning covered `git push`/`fetch` and the integrated terminal, but not the `git` processes `gh` itself spawns: `gh pr create` pushing a branch with no upstream, and `gh pr checkout` fetching, still fell back to the machine credential helper and acted as whichever account it had cached. `GitHubCli.execute` now passes the full auth env instead of the `gh`-only one. Also hardens the env itself: the `GIT_CONFIG_*` pairs are appended after any `GIT_CONFIG_COUNT` already in the parent environment, so an inherited runtime git config is no longer silently overwritten by our pairs claiming indices 0 and 1. A failed or empty `gh auth token` now logs a warning rather than falling back to the ambient account in silence. Adds the tests this path was missing (env shape, inherited-config offset, gh child-process env, terminal spawn env), fixes a `worktreeBranchPrefix` fixture that broke typecheck, and updates the docs note that still claimed plain git pushes were unscoped. Verified against two real gh accounts: with the pin, git authenticates as the selected account while a different one is globally active; without it, git resolves a stale OS keychain entry. Claude Opus 5 (1M context) via Claude Code

enisze · 2026-07-30T11:07:56Z

Problem

Per-project GitHub account pinning (#7) covers git push/fetch and the integrated terminal, but not the git processes gh itself spawns. GitHubCli.execute passed gitHubAccountGhEnv — token only, no credential config — so:

gh pr create pushing a branch with no upstream, and
gh pr checkout fetching

still fell back to the machine credential helper and acted as whichever account it had cached.

Fix

GitHubCli.execute now passes gitHubAccountAuthEnv, so gh's child git processes inherit the same credential config as our own git calls.
gitHubAccountAuthEnv appends its GIT_CONFIG_* pairs after any GIT_CONFIG_COUNT already in the parent env. Previously it hardcoded COUNT=2 and claimed indices 0/1, silently discarding an inherited runtime git config.
Silent fallback is now logged. A failed or empty gh auth token warns instead of quietly acting as the ambient account — that silence is what made the original bug hard to diagnose.
Tests for the path, which shipped without any: env shape (github.com + enterprise), inherited-config offset, malformed GIT_CONFIG_COUNT, gh child-process env, and terminal spawn env.
Drive-by:GitHubAccountResolver.test.ts was missing worktreeBranchPrefix after fix(server): restore access to existing worktrees #7 changed the contract, which broke tsgo --noEmit on main. Fixed.
Docs: the note in source-control-providers.md still said plain git pushes were unscoped. Replaced with what actually holds now, plus the two real limits (terminals pick up the account at spawn; SSH remotes can't be pinned).

Verification

Against two real gh accounts on one machine:

globally active: enisze
pinning to: ezsns
git would authenticate as: ezsns ✅
without the pin (pre-#7 behaviour):
username=15271433 ← stale OS keychain entry, neither account

tsgo --noEmit clean, 259 tests pass across sourceControl/vcs/terminal, lint clean. Targeted checks only, per AGENTS.md — CI owns the full suite. Not exercised through the UI.

🤖 Generated with Claude Code

Per-project GitHub account pinning covered `git push`/`fetch` and the integrated terminal, but not the `git` processes `gh` itself spawns: `gh pr create` pushing a branch with no upstream, and `gh pr checkout` fetching, still fell back to the machine credential helper and acted as whichever account it had cached. `GitHubCli.execute` now passes the full auth env instead of the `gh`-only one. Also hardens the env itself: the `GIT_CONFIG_*` pairs are appended after any `GIT_CONFIG_COUNT` already in the parent environment, so an inherited runtime git config is no longer silently overwritten by our pairs claiming indices 0 and 1. A failed or empty `gh auth token` now logs a warning rather than falling back to the ambient account in silence. Adds the tests this path was missing (env shape, inherited-config offset, gh child-process env, terminal spawn env), fixes a `worktreeBranchPrefix` fixture that broke typecheck, and updates the docs note that still claimed plain git pushes were unscoped. Verified against two real gh accounts: with the pin, git authenticates as the selected account while a different one is globally active; without it, git resolves a stale OS keychain entry. Claude Opus 5 (1M context) via Claude Code

enisze · 2026-07-30T11:07:56Z

Problem

Per-project GitHub account pinning (#7) covers git push/fetch and the integrated terminal, but not the git processes gh itself spawns. GitHubCli.execute passed gitHubAccountGhEnv — token only, no credential config — so:

gh pr create pushing a branch with no upstream, and
gh pr checkout fetching

still fell back to the machine credential helper and acted as whichever account it had cached.

Fix

GitHubCli.execute now passes gitHubAccountAuthEnv, so gh's child git processes inherit the same credential config as our own git calls.
gitHubAccountAuthEnv appends its GIT_CONFIG_* pairs after any GIT_CONFIG_COUNT already in the parent env. Previously it hardcoded COUNT=2 and claimed indices 0/1, silently discarding an inherited runtime git config.
Silent fallback is now logged. A failed or empty gh auth token warns instead of quietly acting as the ambient account — that silence is what made the original bug hard to diagnose.
Tests for the path, which shipped without any: env shape (github.com + enterprise), inherited-config offset, malformed GIT_CONFIG_COUNT, gh child-process env, and terminal spawn env.
Drive-by:GitHubAccountResolver.test.ts was missing worktreeBranchPrefix after fix(server): restore access to existing worktrees #7 changed the contract, which broke tsgo --noEmit on main. Fixed.
Docs: the note in source-control-providers.md still said plain git pushes were unscoped. Replaced with what actually holds now, plus the two real limits (terminals pick up the account at spawn; SSH remotes can't be pinned).

Verification

Against two real gh accounts on one machine:

globally active: enisze
pinning to: ezsns
git would authenticate as: ezsns ✅
without the pin (pre-#7 behaviour):
username=15271433 ← stale OS keychain entry, neither account

tsgo --noEmit clean, 259 tests pass across sourceControl/vcs/terminal, lint clean. Targeted checks only, per AGENTS.md — CI owns the full suite. Not exercised through the UI.

🤖 Generated with Claude Code

Per-project GitHub account pinning covered `git push`/`fetch` and the integrated terminal, but not the `git` processes `gh` itself spawns: `gh pr create` pushing a branch with no upstream, and `gh pr checkout` fetching, still fell back to the machine credential helper and acted as whichever account it had cached. `GitHubCli.execute` now passes the full auth env instead of the `gh`-only one. Also hardens the env itself: the `GIT_CONFIG_*` pairs are appended after any `GIT_CONFIG_COUNT` already in the parent environment, so an inherited runtime git config is no longer silently overwritten by our pairs claiming indices 0 and 1. A failed or empty `gh auth token` now logs a warning rather than falling back to the ambient account in silence. Adds the tests this path was missing (env shape, inherited-config offset, gh child-process env, terminal spawn env), fixes a `worktreeBranchPrefix` fixture that broke typecheck, and updates the docs note that still claimed plain git pushes were unscoped. Verified against two real gh accounts: with the pin, git authenticates as the selected account while a different one is globally active; without it, git resolves a stale OS keychain entry. Claude Opus 5 (1M context) via Claude Code

enisze · 2026-07-30T11:07:56Z

Problem

Per-project GitHub account pinning (#7) covers git push/fetch and the integrated terminal, but not the git processes gh itself spawns. GitHubCli.execute passed gitHubAccountGhEnv — token only, no credential config — so:

gh pr create pushing a branch with no upstream, and
gh pr checkout fetching

still fell back to the machine credential helper and acted as whichever account it had cached.

Fix

GitHubCli.execute now passes gitHubAccountAuthEnv, so gh's child git processes inherit the same credential config as our own git calls.
gitHubAccountAuthEnv appends its GIT_CONFIG_* pairs after any GIT_CONFIG_COUNT already in the parent env. Previously it hardcoded COUNT=2 and claimed indices 0/1, silently discarding an inherited runtime git config.
Silent fallback is now logged. A failed or empty gh auth token warns instead of quietly acting as the ambient account — that silence is what made the original bug hard to diagnose.
Tests for the path, which shipped without any: env shape (github.com + enterprise), inherited-config offset, malformed GIT_CONFIG_COUNT, gh child-process env, and terminal spawn env.
Drive-by:GitHubAccountResolver.test.ts was missing worktreeBranchPrefix after fix(server): restore access to existing worktrees #7 changed the contract, which broke tsgo --noEmit on main. Fixed.
Docs: the note in source-control-providers.md still said plain git pushes were unscoped. Replaced with what actually holds now, plus the two real limits (terminals pick up the account at spawn; SSH remotes can't be pinned).

Verification

Against two real gh accounts on one machine:

globally active: enisze
pinning to: ezsns
git would authenticate as: ezsns ✅
without the pin (pre-#7 behaviour):
username=15271433 ← stale OS keychain entry, neither account

tsgo --noEmit clean, 259 tests pass across sourceControl/vcs/terminal, lint clean. Targeted checks only, per AGENTS.md — CI owns the full suite. Not exercised through the UI.

🤖 Generated with Claude Code

Per-project GitHub account pinning covered `git push`/`fetch` and the integrated terminal, but not the `git` processes `gh` itself spawns: `gh pr create` pushing a branch with no upstream, and `gh pr checkout` fetching, still fell back to the machine credential helper and acted as whichever account it had cached. `GitHubCli.execute` now passes the full auth env instead of the `gh`-only one. Also hardens the env itself: the `GIT_CONFIG_*` pairs are appended after any `GIT_CONFIG_COUNT` already in the parent environment, so an inherited runtime git config is no longer silently overwritten by our pairs claiming indices 0 and 1. A failed or empty `gh auth token` now logs a warning rather than falling back to the ambient account in silence. Adds the tests this path was missing (env shape, inherited-config offset, gh child-process env, terminal spawn env), fixes a `worktreeBranchPrefix` fixture that broke typecheck, and updates the docs note that still claimed plain git pushes were unscoped. Verified against two real gh accounts: with the pin, git authenticates as the selected account while a different one is globally active; without it, git resolves a stale OS keychain entry. Claude Opus 5 (1M context) via Claude Code

enisze · 2026-07-30T11:07:56Z

Problem

Per-project GitHub account pinning (#7) covers git push/fetch and the integrated terminal, but not the git processes gh itself spawns. GitHubCli.execute passed gitHubAccountGhEnv — token only, no credential config — so:

gh pr create pushing a branch with no upstream, and
gh pr checkout fetching

still fell back to the machine credential helper and acted as whichever account it had cached.

Fix

GitHubCli.execute now passes gitHubAccountAuthEnv, so gh's child git processes inherit the same credential config as our own git calls.
gitHubAccountAuthEnv appends its GIT_CONFIG_* pairs after any GIT_CONFIG_COUNT already in the parent env. Previously it hardcoded COUNT=2 and claimed indices 0/1, silently discarding an inherited runtime git config.
Silent fallback is now logged. A failed or empty gh auth token warns instead of quietly acting as the ambient account — that silence is what made the original bug hard to diagnose.
Tests for the path, which shipped without any: env shape (github.com + enterprise), inherited-config offset, malformed GIT_CONFIG_COUNT, gh child-process env, and terminal spawn env.
Drive-by:GitHubAccountResolver.test.ts was missing worktreeBranchPrefix after fix(server): restore access to existing worktrees #7 changed the contract, which broke tsgo --noEmit on main. Fixed.
Docs: the note in source-control-providers.md still said plain git pushes were unscoped. Replaced with what actually holds now, plus the two real limits (terminals pick up the account at spawn; SSH remotes can't be pinned).

Verification

Against two real gh accounts on one machine:

globally active: enisze
pinning to: ezsns
git would authenticate as: ezsns ✅
without the pin (pre-#7 behaviour):
username=15271433 ← stale OS keychain entry, neither account

tsgo --noEmit clean, 259 tests pass across sourceControl/vcs/terminal, lint clean. Targeted checks only, per AGENTS.md — CI owns the full suite. Not exercised through the UI.

🤖 Generated with Claude Code

Per-project GitHub account pinning covered `git push`/`fetch` and the integrated terminal, but not the `git` processes `gh` itself spawns: `gh pr create` pushing a branch with no upstream, and `gh pr checkout` fetching, still fell back to the machine credential helper and acted as whichever account it had cached. `GitHubCli.execute` now passes the full auth env instead of the `gh`-only one. Also hardens the env itself: the `GIT_CONFIG_*` pairs are appended after any `GIT_CONFIG_COUNT` already in the parent environment, so an inherited runtime git config is no longer silently overwritten by our pairs claiming indices 0 and 1. A failed or empty `gh auth token` now logs a warning rather than falling back to the ambient account in silence. Adds the tests this path was missing (env shape, inherited-config offset, gh child-process env, terminal spawn env), fixes a `worktreeBranchPrefix` fixture that broke typecheck, and updates the docs note that still claimed plain git pushes were unscoped. Verified against two real gh accounts: with the pin, git authenticates as the selected account while a different one is globally active; without it, git resolves a stale OS keychain entry. Claude Opus 5 (1M context) via Claude Code

enisze merged commit 390c62c into mainJul 30, 2026

enisze deleted the t3code/sync-selected-github-account branch July 30, 2026 11:08

enisze merged commit 390c62c into mainJul 30, 2026

enisze deleted the t3code/sync-selected-github-account branch July 30, 2026 11:08

enisze merged commit 390c62c into mainJul 30, 2026

enisze deleted the t3code/sync-selected-github-account branch July 30, 2026 11:08

enisze merged commit 390c62c into mainJul 30, 2026

enisze deleted the t3code/sync-selected-github-account branch July 30, 2026 11:08

enisze merged commit 390c62c into mainJul 30, 2026

enisze deleted the t3code/sync-selected-github-account branch July 30, 2026 11:08

enisze merged commit 390c62c into mainJul 30, 2026

enisze deleted the t3code/sync-selected-github-account branch July 30, 2026 11:08

enisze merged commit 390c62c into mainJul 30, 2026

enisze deleted the t3code/sync-selected-github-account branch July 30, 2026 11:08

enisze merged commit 390c62c into mainJul 30, 2026

enisze deleted the t3code/sync-selected-github-account branch July 30, 2026 11:08

Conversation

enisze commented Jul 30, 2026

Problem

Fix

Verification

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Conversation

enisze commented Jul 30, 2026

Problem

Fix

Verification

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Conversation

enisze commented Jul 30, 2026

Problem

Fix

Verification

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Conversation

enisze commented Jul 30, 2026

Problem

Fix

Verification

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Conversation

enisze commented Jul 30, 2026

Problem

Fix

Verification

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Conversation

enisze commented Jul 30, 2026

Problem

Fix

Verification

Uh oh!

Reviewers

Assignees

Labels

Projects