"I Stopped Choosing Between Claude Code and Codex. I Put Both in One Chat Window"

A solution to the frustration of switching between coding agents Claude Code and Codex by integrating both into a single chat window. The author implemented a mode-switching system using simple commands like `/cligate` for assistant-mediated tasks and `/runtime` for direct runtime control, preventing the assistant from intercepting messages meant for the active coding session. This design prioritizes predictable behavior, ensuring that direct runtime messages are not hijacked unless the user explicitly requests assistant intervention.

Every "Claude Code vs Codex" comparison eventually runs into the same boring truth: I do not want to pick one forever. Some tasks feel better in Claude Code. Some feel better in Codex. Some days one account is rate-limited, one model is cheaper, or one runtime is already holding the context I need. The annoying part is not choosing the better agent. The annoying part is switching surfaces every time I change my mind. The workflow I wanted I wanted one local chat window where I could do this: Use Codex for this task. Continue that same runtime. Switch to Claude Code for the next one. Ask the assistant to plan first. Go back to direct runtime mode. That sounds like a UI problem, but it is really a control problem. There are two different things happening: - direct runtime work, where the next message should go straight to Claude Code or Codex - assistant-mediated work, where a supervisor decides whether to answer, ask a question, or delegate to a runtime If those two modes are not explicit, the chat window turns into a trap. A short follow-up like: make it smaller can either mean: - continue the active Codex runtime - ask the product assistant - start a new Claude Code task - answer a pending approval Guessing wrong here is exactly how coding agents become frustrating. So I made direct runtime the default In CliGate https://github.com/codeking-ai/cligate , the chat UI conversation now defaults to direct runtime mode. That was a deliberate choice. Most of the time, when I am using a coding agent, I do not want an assistant to intercept every message and "think about what I meant." I want the current runtime to continue until I explicitly ask for something else. There is a test that pins this behavior: test 'ChatUiConversationStore defaults new chat-ui conversations to direct-runtime control mode', = { const conversation = conversationStore.findOrCreateBySessionId 'chat-ui-default-direct-runtime-1' ; assert.equal conversation.metadata?.assistantCore?.mode, 'direct-runtime' ; assert.equal conversation.metadata?.assistantCore?.controlMode, 'direct-runtime' ; } ; That means a normal chat message does not automatically become "assistant work." It stays on the runtime path. The two commands that made the UI usable I ended up with a small mode switch instead of another complicated settings panel: /cligate /runtime The mode parser is intentionally tiny: js const cligateMatch = trimmed.match /^\/cligate ?:\s+ .+ ?$/is ; if cligateMatch { return { command: 'cligate', args: String cligateMatch 1 || '' .trim }; } if /^\/runtime$/i.test trimmed { return { command: 'runtime', args: '' }; } The behavior is: - /cligate enters assistant mode - /cligate <task runs one assistant-mediated task - /runtime exits assistant mode and returns to direct runtime routing That one escape hatch matters. When I am done asking the assistant to plan or coordinate, I want the next message to go back to the active Claude Code or Codex session without ceremony. The route now decides before touching the runtime The chat route first gives the assistant mode service a chance to handle the message. If assistant mode is not active and there is no /cligate command, it returns null , and the message goes down the normal runtime path: js const assistantResult = await this.assistantModeService.maybeHandleMessage { conversation, text, defaultRuntimeProvider, cwd, model, executionMode: assistantExecutionMode, onBackgroundResult } ; if assistantResult { return { ...assistantResult, previousSessionId: conversation.activeRuntimeSessionId || null, conversation: assistantResult.conversation || this.conversationStore.get conversation.id }; } Only after that does the service route directly to the runtime: js const result = await this.messageService.routeUserMessage { message: { text }, conversation, defaultRuntimeProvider, cwd, model, metadata: { assistantMode: getAssistantControlMode conversation , source: { kind: 'chat-ui', sessionId: String sessionId || '' , conversationId: conversation.id } } } ; That separation is the whole point. The assistant does not get to hijack direct runtime messages just because it exists. Why this is better than a "smart" default I tried to make the assistant helpful. Then I realized "helpful" is dangerous in a coding workflow. If a runtime is waiting for input, the least surprising thing is to send input to that runtime. If a task has a pending approval, the least surprising thing is to resolve that approval. If the user explicitly types /cligate , then the assistant can step in. The result feels less magical, but much easier to trust. For example: fix the failing unit test can start a Codex runtime. Then: try the simpler patch continues that runtime. Then: /cligate compare this failure with the last run before continuing lets the assistant reason over the situation. Then: /runtime puts the conversation back on the direct runtime path. That is the loop I wanted. Background runs needed their own guardrail The other bug showed up after I made assistant runs asynchronous in the chat UI. If an assistant-mediated task starts a runtime and returns later, the UI needs to persist the background result. But it must not append stale output from an older assistant run after the user has already started a newer one. So the route records the pending assistant run ID: if result?.type === 'assistant run accepted' && result?.assistantRun?.id { chatUiConversationStore.patch conversation.id, { metadata: { ... conversation.metadata || {} , uiChatPendingAssistantRunId: String result.assistantRun.id || '' .trim } } ; } And the background callback refuses stale results: if getPendingUiAssistantRunId conversation == backgroundRunId { return; } That is not glamorous, but it prevents a very real UI bug: - start an assistant task - start another task before the first one finishes - watch the old answer appear under the new task No thanks. The model override bug was another small footgun There was one more detail that mattered for a mixed Claude Code / Codex chat surface. The normal chat UI has a local model selector. Runtime routing has its own provider semantics. If I let the local chat model override leak into runtime routing, I could accidentally send something like gpt-5.4 into a Claude Code runtime path where that was not the user's intent. So for local chat-ui runtime messages, the route deliberately ignores the UI chat model override: js const runtimeModelOverride = isExternalConversation ? String model || '' : ''; There is a test for that too: assert.equal captured 0 .model, '' ; assert.equal captured 0 .defaultRuntimeProvider, 'claude-code' ; That tiny rule saved the UI from pretending that "selected chat model" and "runtime provider" are the same concept. They are not. What the setup looks like Start CliGate: npx cligate@latest start Open the dashboard: http://localhost:8081 Then use the Chat page as the control surface: - choose Codex or Claude Code as the runtime provider - send a normal task to start direct runtime work - keep sending follow-ups to continue that runtime - use /cligate when you want assistant-mediated planning or delegation - use /runtime to return to the direct runtime path That is the workflow I wanted from the beginning. Not "which terminal agent wins?" More like: "Can I keep both available without rebuilding my workflow around either one?" The lesson The current wave of AI coding tools makes comparisons tempting. Claude Code vs Codex. Codex vs Gemini CLI. Terminal agent vs IDE agent. Those comparisons are useful, but they miss the day-to-day problem: developers do not just choose tools. They move between them. For me, the useful abstraction was not a smarter chatbot. It was a chat control surface with explicit ownership: - direct runtime by default - assistant mode only when requested - sticky runtime continuation - stale background result protection - no accidental model override leaking into runtime work That made Claude Code and Codex feel less like competing terminals and more like two workers behind the same local desk. If you want to inspect the implementation, the project is here: I'm curious how other people are handling this. Are you choosing one coding agent, or are you building a workflow that lets several of them coexist?