The /codex slash-command surface and the diagnostics paths around it. Part of the Codex harness guide; Where each section moved lists every section.

Commands and diagnostics

The codex plugin registers /codex as a slash command on any channel that supports Apus text commands.

Native execution, control, and host-wide inspection require an owner or an operator.admin Gateway client. This includes binding or resuming threads, sending or stopping turns, changing model, fast-mode, or permission state, compacting or reviewing, detaching a binding, and inspecting account details, host status, native threads, paired-node sessions, MCP servers, or skills. Other authorized senders retain help, model listings, and read-only inspection of their current conversation's binding, model, permissions, Fast mode, and native goal. Host-wide reads are restricted because they can expose other conversations, private workspaces, account identities, and connected services.

Common forms:

When /codex resume attaches a thread without an existing verified harness binding, its next turn checks the native thread's stored tool catalog and applies the current harness configuration before continuing. This first attachment requires the local stdio app-server and its per-agent Codex home. The target native thread must be idle. Apus coordinates attachment, resume, and release of that thread; unrelated chats and catalog reads can continue on the same app-server. If the target thread is active, wait for its turn to finish and retry. Use Codex supervision or native Codex to continue threads in a shared user home or on another app-server.

Native child threads controlled by a parent cannot be attached with /codex resume or /codex bind. Apus reports that restriction and keeps the current binding. Continue the child through its native parent instead.

Codex cannot replace a thread's dynamic tool catalog during resume. If that catalog differs from the current harness tools, its metadata cannot be read, or Codex cannot confirm that it applied the configuration, Apus reports the problem and keeps the selected native thread intact. It does not silently start another thread. Use /new to start with the current harness tools, or continue the preserved thread in native Codex.

If an ordinary Apus-managed native thread was deleted, the next turn starts a fresh native thread while keeping the selected model and provider. This recovery preserves pending manual attachments and native-model-owned threads. It does not replay a turn whose native outcome is uncertain.

For a /codex bind conversation, an app-server restart can unload the bound thread without deleting its history. If Codex rejects the next turn before accepting its input, Apus resumes that same thread and submits the message once more. It does not create a replacement thread. Deleted history, authentication failures, and uncertain turn outcomes stay visible instead of triggering automatic replay. If recovery reports unavailable history, rebind the conversation and resend the message.

Shared Fast mode and Codex fast mode

/fast controls the shared Apus policy. A directive-only /fast off persists off in the Apus session and sends null on affected Codex harness turns to clear the Apus-owned service-tier override. /fast default clears only that session layer, so lower-precedence shared defaults may still resolve to on, off, auto, or ultrafast.

/codex fast instead changes the bound native Codex conversation preference. /codex fast off stores flex for later conversation-bound native turns; it is not a synonym for /fast off, and it does not change the shared Apus session policy. When a shared Fast-mode run control reaches a Codex harness turn, it supersedes plugins.entries.codex.config.appServer.serviceTier and any binding preference that applies to that turn: Fast on starts from priority, Fast off sends null, and auto decides for each model call. The configured or bound native tier is used only when no shared run control is supplied.

Ultrafast requires an effective shared "ultrafast" selection, from a session or run control or an authored fastModeDefault: "ultrafast", and an authenticated app-server catalog that advertises it for the selected native model. An unset appServer.enableUltrafast or true permits that selection; false sends ordinary Fast (priority) instead and skips the Ultrafast catalog check. Fast, active Auto, and unspecified controls never automatically upgrade. A native serviceTier: "ultrafast" also starts from priority until the shared selection requests it. Standard and inactive Auto remain off. See app-server transport for catalog checks and fallback behavior.

/codex fast status and /codex binding report native preference state, not the upstream tier that processed a completed provider request.

For most support reports, start with /diagnostics [note] in the conversation where the bug happened. It creates one Gateway diagnostics report and, for Codex harness sessions, asks for approval to send the relevant Codex feedback bundle. See Diagnostics export for the privacy model and group chat behavior. Use /codex diagnostics [note] only when you specifically want the Codex feedback upload for the currently attached thread without the full Gateway diagnostics bundle.

Inspect Codex threads locally

The fastest way to inspect a bad Codex run is often to open the native Codex thread directly:

codex resume <thread-id>

Get the thread id from the completed /diagnostics reply, /codex binding, or /codex threads [filter].

For upload mechanics and runtime-level diagnostics boundaries, see Codex harness runtime.