tcx-build

Start a Build turn explicitly #

Select the trading-build permission profile and use a new root native Codex task. Put $tcx-build on the first meaningful line as the plain token or a Markdown link that targets this workspace's matching skill. The concrete non-empty request may share that line or follow it.

$tcx-build
Update this workspace to the current compatible package and show the resulting status.

Use it for workspace refreshes, optional role-skill lifecycle work, managed MCP configuration, and connector/provider development. Brain, community Wiki, and Strategy lifecycle mutations use their own exact $tcx-brain, $tcx-wiki, or $tcx-strategy task in trading-research.

What the Build grant does #

The deterministic hook issues a database-canonical grant bound to the current workspace, session, turn, cwd, and original complete prompt. It can support multiple protected managed operations within that root turn; every mutating follow-up or scheduled run requires a new explicit invocation.

Plan mode cannot issue or use the grant, subagents cannot inherit it, and changing the Codex permission mode requires a fresh root turn. Existing attached workspaces receive the new invocation and public-fetch behavior only after tcx update and a full Codex restart. For the provider-specific preparation and connection sequence, continue to From provider to order.

Intent is not permission #

Research already allows reviewable changes to user-owned files outside trading/. Select trading-build for controlled trading/, connector, and optional role-skill lifecycle work. Build uses apply_patch for edits. Its shell allows public HTTP(S) GET/HEAD, enumerated read-only HTTPS Git, limited workspace pwd/cat/ls, inert provider reads/hash/diff/Git inspection, exact isolated py_compile, and allowlisted workspace-launcher commands. General interpreters, helper scripts, test runners, build systems, shell composition, model-authored POST, and native browser/web/network tools are blocked; broader unit, smoke, and build checks run from a user or maintainer terminal. The proxy's full HTTP transport exists only for Git Smart HTTP's protocol POST. Authenticated requests, local/private services, uploads, package installation, fetched-code execution, remote publication, broker calls, and protected TradingCodex state remain denied. Research browser behavior is unchanged.

Build a provider before its connector #

If the provider is missing, Build retrieves public source only into $TRADINGCODEX_SCRATCH/provider-sources/<provider-id>/, records its source provenance, and uses it only for review, hashing, diffing, and static checks. For a new provider available only as direct HTTP(S) files, one curl fetch may use --create-dirs with one URL and one direct <provider-id>/<file> output. That exception creates only the fresh provider-id directory; it does not allow general or nested directory creation, and later files use the existing directory without the flag. Final provider files are written with apply_patch; downloaded code is never installed or executed. A dead-end provider_development_required connector is created first only when you explicitly request scaffold-only output.

Build may inspect the inert final bundle and report its provenance and hash. If the central ledger is unavailable in the sandbox, that result is explicitly bundle-only with service_check_required; it is not approval state. Repeat inspection and approve the exact hash in your interactive terminal, then restart the service. A provenance or helper change invalidates approval. Connector rendering, registration, and validation continue in a fresh Build task after that restart. Raw credentials never enter the prompt or workspace; only credential_ref is stored.