code-moment-switch-model

Code moment: automatically switch to the Codex (newapi/gpt-5.3-codex) workbench

Goal: under thepremise of not changing the main conversation's default model, when a "coding/deployment-type task" is identified, automatically use sessions_spawn(...) to enter the Codex workflow (Flow A). Constraint: webchat does not support a persistent subagent session bound to a thread, so use multi-stage multiple subagent runs to simulate a "workbench".

0) Trigger strategy: generic passphrase + automatic detection

Priority (from high to low):

1. Explicit prohibition(the user says not to use codex)
2. Explicit enablement(generic passphrase: force entering code moment)
3. Automatic detection trigger(based on intent/keywords/structure)

A) Explicit enablement: generic passphrase (force entering code moment)

Any sentence from the user containing the following expressions is considered a forced trigger:

• "code moment" / "enter code moment"
• "enter workbench" / "open workbench"
• "use codex" / "switch to codex" / "codex mode"
• "programming mode" / "coding mode"

B) Explicit prohibition (overrides all automatic triggers)

If any sentence from the user contains the following expressions, then this timedo not trigger/do not switch：

• "no codex" / "don't use codex"
• "don't switch models" / "don't change models"
• "don't use the workbench"

C) Automatic detection trigger (triggers even without a passphrase)

Trigger if any one condition is met:

• Clear coding intent: modify code/write a feature/fix a bug/refactor/add tests/performance optimization/code audit
• Clear engineering/deployment intent: Dockerfile, docker-compose, nginx/caddy, systemd, pm2, CI, build failure, release/rollback
• Clear debugging signals: stack trace, error logs, compilation errors, linter/test fail,diff/patch request
• Input structure signals: presence of a code block ```, file path (such as src/...、/etc/...), command-line output, configuration snippet
• Clear need for multi-file code changes(linkage across multiple source/config files)
• Clear need for a code task requiring verification before build / test / lint / restart

Strong signals for default upgrade to codex (should trigger even if the user does not say "code moment"):

• Multi-file code modification + build verification
• Linked modifications to frontend/backend state machines, routes, components, interfaces, etc.
• Iterative tasks requiring "modify code → build/test → observe results → patch again"

Do not trigger (unless the user forces it with a generic passphrase):

• Pure chit-chat/opinion discussion/product comparison/non-implementation plans
• Translation/polishing only (no code changes)

1) Workbench operating form (subagent, multi-stage run)

1.1 Preferred choice: spawn to codex agent (recommended)

When the runtime environment is already configured with agentId=codex(and agents_list is visible),PriorityStart like this:

{
  "tool": "sessions_spawn",
  "runtime": "subagent",
  "agentId": "codex",
  "model": "newapi/gpt-5.3-codex",
  "mode": "run",
  "cleanup": "keep",
  "task": "..."
}

Reason: fix the default model and boundaries of the "coding workbench" within the codex isolated agent, reducing the probability of the main agent being contaminated.

1.2 Fallback: spawn directly under main

If there is no codex agent (or the allowlist does not permit it), only then fall back to:

{
  "tool": "sessions_spawn",
  "runtime": "subagent",
  "model": "newapi/gpt-5.3-codex",
  "mode": "run"
}

1.3 WORKBENCH_READY handshake (optional but recommended)

Before the formal Patch, you may first initiate a minimal handshake to verify the subagent runtime chain:

• subagent task：Only reply with WORKBENCH_READY
• After the main agent receives the announce, then enter Phase 1 Patch

2) Flow A (mandatory)

Phase 0 — Plan (no changes)

• Clarify goals/acceptance criteria/files involved/risk points/rollback approach

Phase 1 — Patch (produce diff)

• Minimal change implementation
• Output file list + key diff/snippet

Phase 2 — Verify (local verification)

• lint/test/build (run them if possible)
• Output commands + key logs

Phase 3 — Deploy (risk gate)

• Must be explicitly confirmed before execution

Phase 4 — Closeout (wrap-up)

• Summarize changes + verification results + rollback steps

3) Default confirmation (AUTO_CONTINUE)

When the user says:

• "Default confirmation enabled" / "Default confirmation" / "Auto continue"

then:

• Phase 0→1→2 can proceed automatically
• But Phase 3 (Deploy)/restart/deletion/auth routing/firewall still requires explicit confirmation item by item

4) Risk gate (must be explicitly confirmed, even if default confirmation is enabled)

• Any deploy/restart:docker compose up -d、systemctl restart、pm2 reload
• Any destructive: deleting files,git reset --hard, deleting databases/migration
• Any auth/routing/firewall changes: nginx/caddy, token, port, ufw/iptables

5) Process visibility (hard requirement)

• Before entering research/running commands: first say 我在查 X，预计 N 秒
• When the command ends (whether success or failure):查到什么 / 下一步要你确认什么
• During coding execution: report every 1–3 minutes 当前阶段/已完成/下一步/是否要你确认

6) Fallback

If subagent spawning is unavailable:

• Fall back to having the user manually /model newapi/gpt-5.3-codex, still execute according to Flow A.