Summary
Concurrent CLI sessions are not provider-isolated: switching/using Codex provider in one process causes active Command Code-provider sessions in other terminals to fail with 400 Provider not available
Expected Behavior
Multiple Command Code CLI sessions running in separate terminal windows should be able to use different providers concurrently.
For example, one session should be able to continue using a model from the Command Code provider while another independent session uses a model through the ChatGPT Plus/Codex provider.
Selecting or using a different provider in one terminal should not affect already running sessions in other terminals.
Actual Behavior
When I have one or more active CLI sessions using models from the Command Code provider, everything works normally.
If I then start/use another Command Code CLI session in a separate terminal with a model through the ChatGPT Plus/Codex provider, the existing sessions using the Command Code provider stop working on their next request.
They fail with:
Error: 400 Provider not available. Use Command Code provider.
Type "continue" to try again. If the issue persists, contact support: https://commandcode.ai/discord
Example Trace ID:
a409aa6e651ff3abe36ae2446c66d7d4
The affected session/context itself does not appear to be corrupted. The problem seems related to provider selection/routing being shared between concurrently running CLI processes instead of remaining isolated per session.
Steps to reproduce the issue
- Open Terminal A and start a Command Code CLI session using a model from the Command Code provider (for example GLM-5.3-Flash).
- Send prompts and confirm that the session is working normally.
- Leave Terminal A running and open Terminal B.
- In Terminal B, start another Command Code CLI session and select/use a model through the ChatGPT Plus/Codex provider.
- Return to the still-running session in Terminal A and send another prompt (or let an ongoing agentic task make its next model request).
- Terminal A fails with: Error: 400 Provider not available. Use Command Code provider.
- The same behavior occurs with multiple concurrent Command Code-provider sessions: using the ChatGPT Plus/Codex provider in another terminal causes those existing sessions to fail on subsequent requests.
Command Code Version
1.38.2
Operating System
macOS
Terminal/IDE
Terminal
Shell
zsh
Session file (optional)
No response
Fix prompt (optional)
No response
Additional context
OS: macOS Tahoe 26.6.2
Summary
Concurrent CLI sessions are not provider-isolated: switching/using Codex provider in one process causes active Command Code-provider sessions in other terminals to fail with 400 Provider not available
Expected Behavior
Multiple Command Code CLI sessions running in separate terminal windows should be able to use different providers concurrently.
For example, one session should be able to continue using a model from the Command Code provider while another independent session uses a model through the ChatGPT Plus/Codex provider.
Selecting or using a different provider in one terminal should not affect already running sessions in other terminals.
Actual Behavior
When I have one or more active CLI sessions using models from the Command Code provider, everything works normally.
If I then start/use another Command Code CLI session in a separate terminal with a model through the ChatGPT Plus/Codex provider, the existing sessions using the Command Code provider stop working on their next request.
They fail with:
Error: 400 Provider not available. Use Command Code provider.
Type "continue" to try again. If the issue persists, contact support: https://commandcode.ai/discord
Example Trace ID:
a409aa6e651ff3abe36ae2446c66d7d4
The affected session/context itself does not appear to be corrupted. The problem seems related to provider selection/routing being shared between concurrently running CLI processes instead of remaining isolated per session.
Steps to reproduce the issue
Command Code Version
1.38.2
Operating System
macOS
Terminal/IDE
Terminal
Shell
zsh
Session file (optional)
No response
Fix prompt (optional)
No response
Additional context
OS: macOS Tahoe 26.6.2