GitHub plugin installed in ChatGPT is available and implicitly selected in Codex CLI

Start by reproducing the behavior with the GitHub plugin installed in ChatGPT.app, ChatGPT.app running, and no CLI-side plugin opt-in; use codex doctor --json and inspect the session's exposed skills and openai-curated-remote loading. Done means ChatGPT-installed skills are not available or implicitly selected in Codex CLI without explicit opt-in, or can be disabled for the CLI independently.

tl;dr

I don't want the agent to read github:yeet.

What version of Codex CLI is running?

codex-cli 0.145.0

What subscription do you have?

ChatGPT Pro

Which model were you using?

gpt-5.6-sol

What platform is your computer?

Darwin 24.6.0 arm64 arm

What terminal emulator and version are you using (if applicable)?

kitty 0.42.0 (Codex launched through superset / superset.sh)

Codex doctor report

{
  "overallStatus": "ok",
  "codexVersion": "0.145.0",
  "authMode": "chatgpt",
  "platform": "macos-aarch64",
  "model": "gpt-5.6-sol",
  "appServerMode": "ephemeral",
  "relevantEnabledFeatures": [
    "plugins",
    "remote_plugin",
    "plugin_sharing",
    "skill_search",
    "mentions_v2"
  ]
}

What issue are you seeing?

I installed the GitHub plugin in ChatGPT to use the GitHub connector. I did not install or explicitly enable the GitHub plugin in Codex CLI.

However, Codex CLI sessions expose the plugin's bundled skills, including:

• github:github
• github:yeet
• github:gh-fix-ci
• github:gh-address-comments

Codex CLI can also select these skills implicitly. For example, when I made an ordinary request to create a pull request, Codex automatically selected github:yeet even though I had not requested that skill.

This affects CLI behavior because instructions bundled with the ChatGPT-installed plugin are applied to ordinary Codex CLI requests.

This is not new behavior first observed today. Local Codex CLI session history confirms that github:yeet was automatically selected at least as early as July 13, 2026, and it happened again on July 24, 2026.

The issue is not that github:yeet defaults to creating draft pull requests. That workflow behavior is tracked separately in #16127.

The issue here is that installing a plugin for ChatGPT appears to make its bundled skills available to Codex CLI without explicit CLI-side installation or opt-in.

What steps can reproduce the bug?

1. Install the GitHub plugin in ChatGPT and connect GitHub.
2. Keep ChatGPT.app running.
3. Do not install or explicitly enable the GitHub plugin through Codex CLI.
4. Start a new Codex CLI session.
5. Ask Codex to create a pull request without mentioning github:yeet or any GitHub plugin skill.
6. Observe that the session exposes and may automatically select github:yeet.

What is the expected behavior?

Installing a plugin in ChatGPT should not change Codex CLI behavior unless the plugin is explicitly enabled for Codex CLI.

If cross-surface plugin sharing is intentional, Codex CLI should clearly disclose that the plugin and its bundled skills are inherited from ChatGPT and provide a way to disable them for Codex CLI without disconnecting GitHub from ChatGPT.

Additional information

Authentication: ChatGPT sign-in

At the time this behavior was observed, ChatGPT.app was running.

ChatGPT for macOS:

• Bundle identifier: com.openai.codex
• Version: 26.721.30844
• Build: 5813

However, codex doctor --json reported that the Codex background app server was not running.

I have not yet tested whether the GitHub plugin skills remain available after fully quitting ChatGPT.app, so it is currently unknown whether the running desktop app is required for this behavior.

codex doctor --json otherwise reports an overall healthy environment.

The GitHub skills used by the CLI session were loaded from an openai-curated-remote cache. I am not claiming that a particular cache timestamp represents when the behavior started; the behavior predates the current investigation.