Codex Team Workbench
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| PLUGIN_DATA | No | Optional base plugin data directory. When TEAM_WORKBENCH_DATA is not set, the server uses PLUGIN_DATA/team-workbench. | |
| TEAM_WORKBENCH_DATA | No | Optional path to the explicit data directory. When set, it takes precedence over PLUGIN_DATA/team-workbench and the default .team-workbench directory under cwd. |
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 | {} |
| resources | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| team_panelB | Open the persistent shared task board and team map. With boardId, remember that selection if the host supplies anonymous session metadata; {} reopens it. This correlation is not a native Codex thread ID. Does not discover or control agents. |
| team_snapshotB | List boards or read one board, including task revisions and source-labeled member observations. No native agent discovery. |
| team_create_boardB | Create an empty local team board. Does not create any agent or thread. |
| team_bind_sessionA | Bind or explicitly change a board conversation using a full native UUID. A change requires exact previousSessionId, confirmRebind=true and evidence after showing old/new IDs and history isolation to the user. Old members, executions and snapshots retain their original source and cannot be synced under the new origin. Never guess an ID. |
| team_archive_boardA | Archive or restore a workbench after explicit user confirmation of scope. This is reversible; it never deletes tasks, member records, transcripts or project files and does not stop agents. |
| team_observe_runtimeB | Record an actual collaboration list_agents or wait_agent state for the exact recorded runtime path. Evidence and observation time are lead-relayed and not server-authenticated; stale observations cannot overwrite newer ones. resumeAvailable is only true when the lead actually sees the exact agent and has the supported followup tool. |
| team_report_memberB | Record a caller-reported member and state, labeled reported. Does not create, verify, resume, or control a native agent. actor IDs are conventions, not authenticated identities. |
| team_create_taskA | Create an unassigned pending task with optional dependencies. Task assignment alone does not dispatch work to any agent. |
| team_update_taskA | Update a shared task with expectedRevision. Refresh after STALE_REVISION. actorId declares a workflow role, not host identity. Supports claim, release, complete, reopen, edit, dependencies, reassign, soft delete. |
| team_request_executionB | Request native execution through the lead. Starts no agent; the lead must use actual host collaboration tools and record their returned reference. |
| team_record_executionB | Record a real lead spawn receipt, worker start/result, or parent-collected result. These are reported observations, not authenticated runtime telemetry. Never invent runtimeRef or success. confirm completes the task only after worker report and collection. |
| team_record_workflowB | Record an actual caller-owned workflow/run group, with source evidence and revision. This groups agents visually and does not replace their actual parent relationships or start any work. Use expectedRevision=0 for a new group. |
| team_append_recordB | Append an explicitly agent-reported, user-visible work record, not a native transcript. Use a unique recordId for idempotent retry. Do not collect hidden reasoning, credentials, or private session files. All content stays labeled reported. |
| team_read_recordsB | Page recorded work observations, relayed public-host snapshots and execution receipts for one node. Does not directly read native threads or private host sessions/databases. Complete-native access is explicitly distinguished from stored bounded snapshots. |
| team_import_thread_pageB | Relay a bounded page actually returned by the public codex-app-tools.read_thread host tool for an explicitly bound member. Starts no model and calls no host API itself. Exact threadId binding required. Import selected visible messages/status/tool summaries, never reasoning or credentials. Snapshots remain marked agent-relayed, paginated/possibly truncated, not complete native transcripts. |
| team_bind_agent_activityB | Resolve and register one recorded child using exact subAgentActivity path/UUID items relayed from its recorded spawning parent. Does not read host history itself. Never substitutes another parent or guesses a UUID. Returns nextRead only after unique mapping; missing/ambiguous/unavailable sources are stored as visible resolution states. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| Team Workbench |
TDQS
Scored across 16 tools
Most tools have distinct roles, but several recording/observation tools overlap conceptually: team_observe_runtime, team_report_member, team_record_execution, team_record_workflow, team_append_record, and team_import_thread_page all involve relaying or storing evidence with subtle source-label boundaries. team_panel vs team_snapshot also both deal with opening/reading board state, though descriptions help distinguish them.
Almost all tools use a consistent team_ prefix and snake_case, and most follow a verb_noun pattern. The main deviations are noun-like names such as team_panel and team_snapshot, but the overall convention remains predictable.
The server covers a complex workbench domain, so 16 tools is not unreasonable, but it sits at the edge where the set starts feeling heavy. The many recording/observation variants add cognitive load beyond a tightly scoped tool surface.
Core lifecycle operations are covered: boards can be created, viewed, bound, archived, and restored; tasks can be created and updated with claim/release/complete/reopen/soft delete; execution and record workflows exist. Minor gaps remain around explicit board metadata updates or direct task/member listing outside snapshots, but agents can generally work around them.