ChatGPT Work rollover reattaches Git worktree without restoring authenticated remote capability

Summary

ChatGPT Work can reattach a persisted Git linked worktree after a managed-sandbox rollover while silently failing to reprovision—or explicitly invalidate—the shell Git authentication capability associated with that workflow.

The resulting workspace looks intact and remains fully usable for local Git operations, but authenticated remote operations fail. This creates a dangerous partial-resume state: edits, commits, and test evidence survive, while the ability to fetch or publish them does not.

This is related to #37986, which reports the broader missing bridge between an authenticated GitHub plugin and a generic Work sandbox. This report is narrower: lifecycle consistency across sandbox rollover when the Git workspace itself is preserved and reattached.

Affected component

• ChatGPT Work / Codex Work Mode
• Managed Linux remote sandbox
• Sandbox lifecycle / rollover / rehydration
• GitHub-connector-to-shell capability provisioning
• Subscription: ChatGPT Pro
• Observed: 2026-09-13

Observed sequence

1. A long-running engineering workflow used Git linked worktrees and synchronized branches with a private GitHub repository.
2. The execution runtime later rolled over or was rehydrated.
3. The Git workspace survived and was reattached:
   • the active worktree was under one scratch allocation;
   • its .git administrative file still pointed to the common Git store under an earlier scratch allocation;
   • preserved repository/worktree modification times predated the current runtime home.
4. The new runtime home/process environment contained no shell Git authentication path.
5. Local Git operations still worked, but the authenticated read-only remote probe failed.

The retained evidence establishes the reattachment mismatch, but cannot determine whether the rollover was caused by cache expiry, ordinary session resumption, or a platform rollout. It also cannot determine which transient authentication mechanism had been available before the rollover.

Sanitized diagnostics

Remote:

https://github.com/<org>/<private-repo>.git

Worktree topology:

/workspace/scratch/<current-allocation>/<worktree>/.git
  -> /workspace/scratch/<earlier-allocation>/<repo>/.git/worktrees/<worktree>

Post-rollover authentication inventory:

credential.helper: absent
core.askpass: absent
http.*.extraheader: absent
GIT_ASKPASS: absent
SSH_ASKPASS: absent
GITHUB_TOKEN: absent
GH_TOKEN: absent
SSH_AUTH_SOCK: absent
~/.git-credentials: absent
~/.config/gh/hosts.yml: absent
~/.netrc: absent
gh executable: unavailable

Read-only probe:

$ GIT_TERMINAL_PROMPT=0 git ls-remote origin HEAD
fatal: could not read Username for 'https://github.com': terminal prompts disabled

The authenticated GitHub connector remained able to access the repository, so repository authorization still existed in the Work control plane; it was not available to shell Git.

Expected behavior

On sandbox rollover, Work should preserve a consistent repository capability state. If an authorized Git workspace is reattached, it should do one of the following:

1. Reissue a short-lived, repository-scoped, non-model-visible Git credential/helper for the new runtime; or
2. Re-materialize the repository through a host-side authenticated operation; or
3. Mark shell Git remote access explicitly unavailable before work starts and expose a supported reauthorization/publishing path.

A persisted worktree should not silently imply a push-capable environment when only the filesystem half of the workflow survived.

Security requirements

This report is not requesting that raw OAuth tokens or long-lived credentials be persisted across sandboxes. A safe implementation should use:

• newly minted short-lived credentials after each rollover;
• repository/ref and operation scoping;
• no model-visible token values;
• audited issuance and use;
• automatic revocation at task completion;
• an explicit capability status such as:
  • repository mounted;
  • connector authorized;
  • shell Git authenticated;
  • fetch allowed;
  • push allowed.

Impact

• Validated local work can become stranded after a transparent runtime rollover.
• Long-running and multi-agent workflows lose reliable checkpoint/push guarantees.
• Agents may incorrectly infer that an intact worktree is fully operational.
• The gap encourages fragile low-level object/file API reconstruction instead of normal atomic Git workflows.
• Diagnosis consumes time because the UI does not distinguish persisted filesystem state from authenticated remote capability.

Suggested regression test

1. Provision an authorized private-repository Work task with a real linked worktree.
2. Verify an authenticated, non-mutating remote probe.
3. Force a sandbox rollover while preserving the workspace volume.
4. Resume the task.
5. Verify that either:
   • a newly issued brokered credential makes the same probe succeed; or
   • the runtime reports a structured, actionable unavailable-auth state before shell work begins.
6. Confirm that no credential value is present in the model-visible environment or filesystem.

Privacy

No token, credential, username, private source, repository name, or proprietary path is included in this report.

No repository files or existing test entry points are named. Start by tracing sandbox rollover and rehydration, linked-worktree reattachment, and GitHub connector-to-shell capability provisioning. Use the suggested regression sequence with git ls-remote and verify that resume either restores scoped authentication or reports an actionable unavailable-auth state without exposing credentials.