VS Code extension and Codex CLI cannot be used simultaneously due to session conflict

Open 💬 3 comments Opened May 16, 2026 by see7788
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What happened?

When using the Codex VS Code extension and Codex CLI at the same time, they cannot run concurrently. One side reports a session-related error/conflict instead of allowing independent use.

This feels like a bug because the VS Code extension session and a separate Codex CLI session should either:

  • be able to run independently at the same time, or
  • show a clear, actionable message explaining that a shared session lock is intentional and how to avoid it.

Expected behavior

I should be able to keep Codex open in VS Code and also run codex / Codex CLI in a terminal without one interface breaking the other because of session state.

Actual behavior

Using VS Code Codex and Codex CLI side by side causes a session-related failure. The tools appear to conflict over session state, so only one can be used reliably at a time.

Environment

  • OS: Windows
  • Codex CLI: codex-cli 0.129.0
  • VS Code extension: openai.chatgpt@26.513.21555
  • Repo/workspace path type: local Windows workspace

Notes

The exact error text was not captured yet, but the failure is session-related and appears specifically when both the VS Code extension and CLI are active. If needed, I can add the exact error message after reproducing it again.

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 3 months ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #21782

Powered by Codex Action

etraut-openai contributor · 3 months ago

Does this happen every time, or is it intermittent?

If you see this again, please post the error message.

fatihtan · 3 months ago

I found another possible root cause / trigger.

This does not seem to be only a version downgrade issue. I reproduced/tested with:

  • openai.chatgpt 26.513.21555
  • openai.chatgpt 26.506.31421

The important difference is the initial permission mode:

  • Starting Codex with Full Access as the initial permission mode breaks the sidebar/message sending on my side.
  • Starting Codex with Default permissions works.
  • When Codex later asks for permission through the prompt flow, it also works.

After switching back to Default permissions, I upgraded again to 26.513.21555 and Codex is working.

So my current hypothesis is:
Full Access cannot be reliably applied as the first/initial permission state. The extension seems to enter a broken sidebar/session state when Full Access is selected upfront.

Start with Default permissions first and let Codex request permission through the prompt flow instead of starting directly with Full Access.