codex-thread-bridge
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| CODEX_HOME | No | Codex home directory. Defaults to ~/.codex. Used to locate the App Server control socket at $CODEX_HOME/app-server-control/app-server-control.sock. | ~/.codex |
| XDG_STATE_HOME | No | Base directory for user state. Receipts are stored under $XDG_STATE_HOME/codex-thread-bridge (default ~/.local/state/codex-thread-bridge). | ~/.local/state |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| get_capabilitiesA | Check connection and report implemented capabilities and compatibility limits. |
| create_threadA | Create a retained session in an existing cwd, optionally with an initial prompt. Requires approval of this action and sandbox. No worktree or persistent Goal is created. Approval policy is never. Omitted model/reasoning use configured defaults. Supply only an App Server project ID, never assume a Desktop saved-project ID is interchangeable. Returns actual settings and IDs; verify Desktop association separately. Reusing request_id returns its receipt without resending. A failed/unknown operation may have created a thread. |
| create_worktree_threadA | Create a retained, locked Git worktree and a task at an approved full commit ID. Requires approval of bridge-managed-retained ownership, source checkout root, immutable commit, absent absolute destination (existing parent), permissions and exact prompt. Creates a detached checkout and Git metadata; disables hooks/filters, copies no dirty files, runs no setup, sets no Goal. No automatic cleanup, archive or Desktop binding. Approval policy is never. expected_sandbox_policy is the complete expected response: e.g. {"type":"readOnly","networkAccess":false}. Actual settings and workspace roots must match before prompt dispatch. Omit prompt for readiness-only creation; caller owns further readiness and Goal policy. Model/reasoning defaults are preserved when omitted. Reuse request_id after uncertainty: receipts replay without continuing partial work. Known artifacts and recovery requirements are retained even on failure/cancellation. |
| send_message_to_threadA | Resume the explicitly selected idle session without overrides and send one message. Requires user authorization. Refuses an active thread and an interactive approval policy. Resume may load the session; its actual settings are returned. Does not steer, interrupt, set Goals, or retry delivery. Use a stable request_id; inspect get_operation on uncertainty. |
| list_threadsA | List unarchived backend threads without loading them. Project IDs are backend IDs. |
| read_threadA | Read metadata and one newest-first turn page, without resuming; truncation is marked. |
| wait_threadA | Wait up to 50 seconds for a specific recent turn, without resuming or interrupting it. Zero returns one snapshot. A timeout leaves the turn running. Only the latest 100 turns are inspected; use read_thread pagination for older turns. Completion can mean failure or interruption: inspect turn.status. The response never substitutes another turn. |
| get_goalB | Read persistent Goal state without modifying it; text over 4000 characters is marked. |
| get_operationA | Read a mutation receipt, including known IDs after partial or uncertain delivery. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 9 tools
Each tool targets a clearly distinct action: capabilities, thread creation variants, listing/reading/waiting, goal inspection, and operation receipt inspection. Even the two creation tools are sharply separated by the worktree behavior, and send_message_to_thread has no overlap with the create or read tools.
All tool names are lowercase snake_case and verb-led, following a consistent verb_noun structure such as create_thread, list_threads, read_thread, get_goal, and get_operation. The one compound name, send_message_to_thread, is still semantically aligned and does not introduce a different convention.
Nine tools is well within the ideal range for a bridge server. Each tool covers a distinct lifecycle or inspection concern without redundancy, and the count feels proportionate to the domain.
The core workflow is well covered: create threads, send messages, read/wait on turns, and inspect goals or operation receipts. Minor gaps exist around thread lifecycle management (no archive/delete) and goal mutation, but these appear intentionally left to external ownership and can be worked around.