›_ Codex Issues
Codex Issues / #37986

ChatGPT Work remote sandbox cannot use authenticated GitHub plugin for repository checkout

Open 💬 0 comments Opened Aug 11, 2026 by natbusa

Classification correction

This is a ChatGPT Work remote-runtime limitation, not a Codex engine, Codex CLI, or Codex Cloud limitation.

Codex works correctly when it is launched in a repository-backed development environment with normal Git authentication. The failing layer is ChatGPT Work's generic remote sandbox and the missing bridge between that sandbox and the GitHub plugin authenticated in the Work control plane.

This issue is filed in openai/codex because OpenAI's public troubleshooting documentation currently routes product bug reports to this issue tracker. If the owning component is maintained elsewhere, please route it internally to the ChatGPT Work runtime/connectors team.

Summary

In ChatGPT Work, the GitHub plugin can be authenticated and can perform structured repository operations, but the plugin's authenticated repository context cannot be materialized into the remote shell sandbox.

As a result, a Work task that requires the standard engineering workflow—

clean checkout -> edit -> run local validation/tests -> one commit -> push

—cannot be completed from a generic Work sandbox, even though the same GitHub account and private repository are accessible through the connected plugin.

This materially reduces ChatGPT Work's effectiveness for engineering workflows compared with a normal Codex run in a properly provisioned development environment.

Affected component

  • Affected: ChatGPT Work remote sandbox provisioning
  • Affected: ChatGPT Work GitHub-plugin-to-sandbox integration
  • Not affected: Codex reasoning/model behavior
  • Not affected: Codex CLI when run in an authenticated local repository
  • Not affected: repository-backed Codex development environments
  • GitHub access: authenticated GitHub plugin with access to a private repository
  • Model used during observation: GPT-5.6-sol
  • Date observed: 2026-08-11
  • Client initiating the Work task: ChatGPT Android app

Steps to reproduce

  1. Connect and authenticate the GitHub plugin in ChatGPT Work.
  2. Confirm that the plugin can read and write an accessible private repository.
  3. Start a ChatGPT Work task that requires:
  • a clean checkout of the repository's default branch;
  • local edits;
  • repository-native validation such as npm run validate && npm test;
  • one atomic commit;
  • a push back to the default branch.
  1. Inspect the Work remote shell workspace.
  2. Attempt to clone the private repository with git clone.

Actual behavior

  • ChatGPT Work provisions an empty/generic scratch workspace rather than a repository-backed checkout.
  • git is present, but the shell has no GitHub credentials.
  • gh is unavailable.
  • The GitHub plugin's OAuth credential remains in the connector/control plane and is not usable by shell Git operations.
  • The plugin exposes structured operations such as fetching files and creating Git objects/commits, but no secure repository checkout/materialization operation and no short-lived credential-helper operation.
  • Therefore, shell-level git clone, pull, and push cannot use the GitHub connection already authenticated in ChatGPT Work.
  • Plugin-level file/object mutations cannot substitute safely for a normal local workflow when repository-native validation must run before a single atomic commit.

This gap can also push a Work agent toward inappropriate API-level reconstruction or per-file mutation workarounds, bypassing the intended local test-before-commit workflow.

Expected behavior

When a ChatGPT Work task has an authenticated GitHub plugin and the user authorizes work on an accessible repository, the Work runtime should provide one of the following:

  1. A repository-backed remote sandbox already checked out at the requested ref; or
  2. A secure host-side checkout_repository / materialize_repository operation that places a real Git worktree in the sandbox; or
  3. A short-lived, repository-scoped Git credential helper that supports normal clone, fetch, pull, and push without exposing the OAuth token to the model.

The result should support this invariant:

checkout exact ref -> edit locally -> run repository validation -> commit all related files once -> push

If validation fails, no commit or push should occur.

Security requirements

The GitHub plugin's OAuth token should remain outside model-visible context and should not be written into the sandbox environment. A safe design could use:

  • host-side checkout/materialization;
  • a brokered Git credential helper with a very short lifetime;
  • repository/ref-scoped authorization;
  • operation auditing;
  • automatic credential revocation at task completion.

Impact

This is a high-impact ChatGPT Work workflow gap:

  • private repositories accessible to the Work plugin are not practically usable by local build/test tooling;
  • Work agents cannot reliably obey repository validation gates before publishing;
  • normal atomic Git semantics are lost;
  • users must switch from ChatGPT Work to a separate repository-backed Codex environment;
  • the plugin appears authenticated in Work, but the remote runtime required to act on that repository is not provisioned.

Suggested UX/diagnostics

ChatGPT Work should explicitly distinguish:

  • GitHub plugin connected;
  • repository mounted/materialized;
  • shell Git authenticated;
  • push permission available.

If the plugin is connected but no checkout bridge exists, the Work agent should receive a structured blocker instead of being left to infer the mismatch from a failed git clone.

View original on GitHub ↗