Open and check the workspace without changing it

A healthy workspace task starts with direct read-only Viewer and Wiki links. Use the server skill for readiness, update, MCP, and recovery diagnostics.

Read the skill page #

01tcx-serverCheck readiness and receive safe recovery guidance.→

Primary

`tcx-server`

Explain workspace and service health, update readiness, MCP and OpenBB data-source state, database posture, and recovery guidance.

Use it when: The workspace is not ready, you need the viewer URL, MCP needs checking, or you want guided OpenBB provider setup without exposing a key.
What it does: Uses the smallest trusted read-only status surface and interprets hook startup context plus read-only status, update, and data-source tools.
What it returns: Runtime status, a recovery command, OpenBB credential-reference guidance, a viewer URL, update guidance, or a clearly stated blocker.
Boundary: It never asks for a raw key, provisions OpenBB, runs service commands through the model shell, performs investment judgment, or makes a workspace change.

Check readiness

$tcx-server
Is this workspace ready for a new analysis?

Use the terminal for explicit operations #

When a service, doctor, update, recovery, or OpenBB data-source configuration command requires the launcher, the skill gives you the exact user-terminal handoff rather than running it through the model shell. That keeps maintenance operations clearly operator-owned.

Common readiness checkshell

./tcx doctor
./tcx service ensure

When a healthy compatible service is available at the start of a new task, Codex shows direct Viewer and Wiki links in a system message. An incompatible or unreachable service exposes no viewer URL. When a newer TradingCodex release is also detected, the same message includes the workspace and latest versions, the exact workspace update command, and the required restart step. No update runs automatically.

The default doctor view shows layer totals and expands warnings or failures. Use ./tcx doctor --verbose when you need every PASS check. A package refresh launched with uvx ... tcx update preserves the workspace's recorded custom runtime home, DB override, and service address unless you explicitly provide replacements. On native Windows PowerShell, use .\tcx.cmd doctor, .\tcx.cmd doctor --verbose, and .\tcx.cmd service ensure.

Updating to 1.2.0. Pin both sides of the update with uvx --refresh --from "tradingcodex==1.2.0" tcx update . --from "tradingcodex==1.2.0", then run ./tcx doctor. On native Windows PowerShell, run the same pinned uvx command, then run .\tcx.cmd doctor. Fully quit and restart Codex afterward and open a new task. User-installed MCP servers, skills, and plugins remain Codex-owned BYOR capabilities; TradingCodex refreshes only its reserved projections.

What the viewer can show #

The local workspace viewer is a read-only projection. It can show Library, Skills, and System information for registered attached workspaces, but it never launches or resumes Codex, creates an analysis run, modifies a skill, or offers a browser exception to policy and execution boundaries.

The System capability list is a sanitized configuration inventory, not the current task's tool list. An enabled plugin, app, MCP server, or skill may require a new task—or a full Codex restart after an install or update—before its tools appear. TradingCodex does not disable Codex apps in generated workspace configuration; user, organization, and host policy remain in control. In an analysis task, TradingCodex checks current callable tools and attempts the relevant read-only provider call before reporting that data is unavailable.

Use a new native Codex task for agent work. The viewer is where you inspect the workspace; the trusted Codex workspace is where research and managed skills run.