GitHub connector authority is visible, then tools become unavailable mid-session

What issue are you seeing?

The GitHub connector can expose valid authenticated identity and repository authority, then become unavailable later in the same authenticated working period after a bounded GitHub operation.

This is not one stable 403 permission failure. Across repeated ChatGPT/Codex sessions, the observed state has transitioned between:

• repository reads working;
• writes returning 403 Resource not accessible by integration;
• full revoke/reinstall/reconnect succeeding;
• authenticated account identity and admin collaborator permission becoming visible;
• then a later source search, harmless first write attempt, or independent readback causing the GitHub connector/tool namespace to become unavailable/disabled.

A separately authenticated GitHub CLI control route remained able to read or mutate the same user-owned repository state during these native-connector failures.

This makes the connector difficult to use safely for workflows that require write -> independent readback, because disappearance of the readback tool cannot be interpreted as evidence that the write failed.

Observed state transition

flowchart LR
  A[Revoke / reinstall / reconnect] --> B[Authenticated identity visible]
  B --> C[Repository permission read: admin]
  C --> D{Later bounded GitHub operation}
  D -->|source search| E[Connector/tool unavailable]
  D -->|first harmless write| E
  D -->|independent readback| E
  E --> F[Separate governed GitHub CLI route still reaches repository]

FACT

• Historical baseline: the native connector could read repository state while writes returned 403 Resource not accessible by integration.
• After a full revoke/reinstall/reconnect with all-repository read/write authorization, the native connector resolved the expected authenticated account and returned admin collaborator permission on a user-owned repository.
• During the same working period, a first harmless write path did not reach a stable postcondition because the connector became unavailable/disabled rather than consistently returning the earlier 403 class.
• A native source-search path and a later branch-creation attempt caused the connector to become unavailable in separate bounded probes.
• On 2026-09-04, the connector schemas could again be discovered, but an independent PR/issue readback attempt caused the connector to become disabled; exact remote SHA/PR state remained readable through the separate GitHub CLI control route.
• Reauthorization changed visible connector state but did not make it stable.

INFERENCE

The observations are consistent with runtime/session-scoped connector authority or tool-registry state becoming invalid after successful initialization. They are not sufficient to identify whether the root cause is GitHub App installation-token propagation, an authorization cache, MCP/tool registry refresh, worker/session state, or another platform layer.

UNKNOWN

• Whether the triggering GitHub operation matters or merely encounters already-stale connector state first.
• Whether the failure scope is chat/thread lineage, runtime worker, connector session, or account-wide.
• Whether the same failure can be reproduced deterministically from a fresh minimal session without the longer workflow context.

Related issues

These reports overlap with individual symptoms but do not appear to cover the same longitudinal state transition:

• #37330 — reconnect succeeds but repository/write authority remains broken.
• #39018 — selective read endpoints return 403 Resource not accessible by integration.
• #38146 — user authorization, App installation, and repository grant can disagree.
• #40729 — all GitHub tools disappear after granting private-repository access.

This report adds repeated evidence for:

authority visible
-> operation attempted
-> native connector/tool path disappears
-> independent control route still reaches GitHub

Sanitized evidence bundle

Public longitudinal packet (no tokens, installation IDs, private repository names, or private conversation text):

• Markdown: https://github.com/TeaShaman-cyber/marcopolo-cookbook/blob/7cd4a7fc662eca1c2f67c406eae46b5c5849ad3f/docs/evidence/2026-09-04-openai-github-connector-instability.md
• JSON: https://github.com/TeaShaman-cyber/marcopolo-cookbook/blob/7cd4a7fc662eca1c2f67c406eae46b5c5849ad3f/docs/evidence/2026-09-04-openai-github-connector-instability.json

The bundle was reconstructed from repeated session evidence and current live probes, then sanitized before publication.

Minimal distinguishing reproduction

1. Connect/reconnect the GitHub connector and grant repository access.
2. Read authenticated identity / repository metadata / collaborator permission and confirm an authorized repository is visible.
3. In the same session, perform several small operations separately rather than as one compound workflow:
   • a source/file search;
   • a harmless branch/write operation on a disposable repository, if authorized;
   • an independent readback of repository/PR/issue state.
4. After each operation, confirm whether the GitHub tool namespace remains available.
5. If it becomes unavailable, verify the repository through a separate GitHub client using the same human account but independent authentication.

Expected: connector capability remains stable, or returns a precise authorization/error result for the attempted operation.

Observed in affected sessions: the native connector/tool path can disappear entirely after previously demonstrating authenticated repository authority.

Impact

For engineering workflows this forces a second GitHub route solely for reconciliation. Without it, an agent cannot safely distinguish:

write failed
!=
write succeeded but readback connector disappeared
!=
repository permissions changed

The practical result is repeated reauthorization, workflow interruption, manual recovery, and loss of confidence in connector postconditions.

Privacy boundary

The attached evidence intentionally omits tokens, cookies, GitHub App installation IDs, private repository names, private commit identifiers, account-private URLs, and raw conversation contents.

Prepared collaboratively by Semyon Poklad and Шут (Jester), an AI engineering partner in the Theseus research workspace. Submitted with Semyon Poklad's explicit approval.

Start with the minimal distinguishing reproduction and the GitHub connector/tool namespace behavior described in the issue. Compare the sanitized evidence files docs/evidence/2026-09-04-openai-github-connector-instability.md and .json, then verify whether the connector remains available after each bounded operation and returns a precise result instead of disappearing.