Newer Codex CLI rejects interactionMode: default, causing chat turns to hang with no response

[alexprotonotarios]

T3 Code v0.0.4 appears to be incompatible with newer Codex app-server interaction mode names during normal chat turns.

What happens

The app starts and the session initializes normally, but sending a standard chat message causes the UI to hang with no assistant response. In the UI this looks like the message sending successfully while the assistant never replies.

Repro

1. Install T3 Code v0.0.4 from the March 7, 2026 release.
2. Have a local Codex CLI installed at codex-cli 0.94.0.
3. Open any project and send a normal chat message like hi.
4. Observe that the turn never produces a response.

Relevant log

From ~/.t3/userdata/logs/server-child.log:

Provider adapter request failed (codex) for turn/start: turn/start failed: Invalid request: unknown variant 'default', expected one of 'plan', 'code', 'pair_programming', 'execute', 'custom'

Suspected root cause

T3 Code still models provider interaction mode as default | plan and appears to send default for normal chat turns. The local Codex app-server schema now expects newer mode values including code instead of default.

Relevant source locations:

• packages/contracts/src/orchestration.ts
• apps/server/src/codexAppServerManager.ts

Locally, a simple compatibility patch that remaps default -> code before forwarding the turn request makes the app usable again.

Why this seems distinct from #360

Issue #360 covers older Codex CLIs causing session startup to fail. This looks like the opposite compatibility problem: the session starts, but newer Codex CLIs reject normal chat turns because the interaction mode name has drifted.

Suggested fix

• Translate default to code when talking to newer Codex app-server versions, or
• update T3 Code's interaction mode model to match current Codex app-server values and preserve backward compatibility where needed.

Happy to provide more log context if useful.

[alexprotonotarios]

I verified a local workaround that makes the app usable again with newer Codex CLIs.

The narrow fix is at the adapter boundary in apps/server/src/codexAppServerManager.ts, where buildCodexCollaborationMode currently forwards input.interactionMode directly and still types it as "default" | "plan".

In v0.0.4, this currently behaves like:

• packages/contracts/src/orchestration.ts defines ProviderInteractionMode as default | plan
• buildCodexCollaborationMode(...) returns mode: input.interactionMode

A simple compatibility patch that remaps normal chat mode before sending the turn request fixed the hang locally:

const mappedMode = input.interactionMode === 'default' ? 'code' : input.interactionMode;

return {
  mode: mappedMode,
  settings: {
    model,
    reasoning_effort: input.effort ?? 'medium',
    developer_instructions:
      input.interactionMode === 'plan'
        ? CODEX_PLAN_MODE_DEVELOPER_INSTRUCTIONS
        : CODEX_DEFAULT_MODE_DEVELOPER_INSTRUCTIONS,
  },
};

So at least for newer Codex app-server builds, default -> code appears to be the missing compatibility translation.

This was enough to get normal chat turns responding again on my machine without changing auth or project settings.

[hwanseoc]

codex-cli 0.94.0

Isn't the newest codex-cli version 0.111.0?

[alexprotonotarios]

Update after retesting: a clean reinstall changed the outcome on my machine.

I fully uninstalled T3 Code, removed local T3 state (~/.t3 and ~/Library/Application Support/T3 Code (Alpha)), updated my local Codex CLI from 0.94.0 to 0.111.0, and then reinstalled a fresh unmodified v0.0.4 app.

With that setup, the stock app now works correctly for me.

So my earlier report likely overstated the root cause. The best current explanation is:

• the failure was caused by the older local Codex CLI version (0.94.0), and/or
• stale local T3 state from the previous install contributed to it

In other words, this does not currently look like a general v0.0.4 + newer-Codex incompatibility on my machine anymore.

Sorry for the confusion there.

I still think there is a useful product issue here: when the underlying local Codex CLI is too old or otherwise incompatible, it would help if T3 Code surfaced an explicit warning/version check instead of silently hanging or failing in a way that requires log inspection.

That would make this class of setup issue much easier to diagnose.

[shivamhwp]

so basically it's better to install the latest versions of both the app and the cli.
i think there might be a pr which let's you see which version you have installed etc.
so closing this issue for now !!