TradingCodex: a multi-agent investment research team inside Codex

The gap TradingCodex fills: research that survives the chat window

Most AI-assisted investment work dies in the conversation. You ask a model about a company, get a plausible answer, and lose the reasoning the moment the window closes. TradingCodex is built against that failure. Its stated design is research-first, local-first, and paper-first, and the README is explicit that a research answer never becomes a broker action on its own.

The target user is someone who already works inside the Codex CLI and wants a repeatable research process rather than a chatbot. A single question goes in ordinary language, and the project routes it through a team of nine named specialist agents: Fundamental Analyst, Technical Analyst, News Analyst, Macro Analyst, Instrument Analyst, Valuation Analyst, Portfolio Manager, Risk Manager, and Judgment Reviewer. Each has a defined remit. The Judgment Reviewer exists to challenge evidence and confidence rather than to agree with the other eight.

That is a different proposition from a screener or a backtesting library. TradingCodex does not compute indicators for you or place orders. It organizes the reasoning step and keeps the evidence on disk.

How the Head Manager picks a team instead of running a fixed pipeline

The mechanism the README describes is a loop, not a preset research DAG. The Head Manager reads the mandate, chooses what the documentation calls the smallest useful group of agents, runs independent work in parallel where that helps, and revises the team when accepted evidence exposes a new gap or conflict.

The published flow is short enough to quote as a shape: question, then Head Manager, then the smallest useful specialist wave, then accepted evidence and artifacts, then a decision to follow up, add a role, request review, synthesize, or stop. The next agent is chosen by the next useful question. A narrow question can stay direct. A high-consequence recommendation can expand into independent portfolio, risk, and judgment review.

This is the part worth judging. Dynamic routing means the same ticker does not always travel the same path, which is closer to how an analyst actually works than a fixed checklist. It also means the workflow is harder to reproduce exactly, since the team composition depends on what the manager decides mid-run. The README does not document a way to pin a fixed agent set for a given query.

Underneath the loop sits a static layer the project treats as the real product: Research Memory holds source snapshots, datasets, reports, forecasts, decisions, calculations, provenance, and evidence gaps. A Knowledge Wiki holds reusable background, with the caveat that wiki content is context and not current evidence. Investment Brain holds inquiry principles, causal frames, falsifiers, limits, and abstention rules. Decision Memory holds prior judgments, outcomes, postmortems, and lessons. Strategy holds user-owned decision rules. The README keeps these distinct on purpose: a wiki does not become proof, a Brain does not choose agents, and an improvement record does not silently rewrite prompts or execution gates.

Installing TradingCodex and running a first research question

The README is direct about placement: attach TradingCodex to the folder where you want research to live, and do not clone the source repository into that workspace. You need Git, uvx, and an installed, authenticated codex CLI.

On macOS or Linux, the documented sequence creates the workspace, attaches the tool, runs a health check, and starts the background service:

cd /path/to/an/empty-workspace
uvx --refresh --from tradingcodex tcx attach . && ./tcx doctor
./tcx service ensure

On native Windows PowerShell the same steps use the .cmd wrapper:

cd C:\path\to\an\empty-workspace
uvx --refresh --from tradingcodex tcx attach .
.\tcx.cmd doctor
.\tcx.cmd service ensure

After installation the README asks you to fully restart Codex, reopen and trust the workspace, and approve every TradingCodex hook when Codex prompts you, one at a time if they arrive that way. The viewer URL is printed by ./tcx service status, with a release default of http://127.0.0.1:48267/. End users do not need Node, npm, or a separate frontend server.

The first real use is a skill invocation pasted into a new Codex task. The README gives three examples. To frame scope before any analysis:

Clarify a 3-year MSFT quality-compounder mandate. No order.

To run the dynamic workflow with the smallest useful team:

Analyze MSFT as a medium-term quality compounder. Include contrary evidence. No order.

To replay a prior judgment against what was known at the time:

Review the last MSFT thesis against what was known then.

Each maps to a named skill: $tcx-plan, $tcx-workflow, and $tcx-memory. What you should see afterward is a populated workspace, with the README's documented layout of trading/research for snapshots and artifacts, trading/reports, trading/forecasts, trading/decisions, plus wikis and investment-brains directories at the top level. The Head Manager inherits the active Codex model and reasoning setting; the README recommends gpt-5.6-sol with high or xhigh reasoning for full research workflows.

Where TradingCodex stops: no execution agent, no TradingView connection

The README states plainly that there is no execution agent. Research output is not a broker action, and the project describes itself as paper-first. If your goal is an automated trading bot that places orders, TradingCodex is the wrong tool by design, not by missing configuration. It produces judgments, forecasts, and decision records for a human to act on elsewhere.

A second boundary is data. The README lists what the static layers store, but it does not document bundled market data feeds or a charting interface. The related search terms around TradingView and market connectivity are not addressed in the README. Treat connectivity as something to verify in the user guide rather than assume.

The dynamic routing has a cost too. Because the Head Manager chooses the team per question, two runs of the same prompt may not produce identical agent paths, and the README documents no mechanism for freezing that choice. Teams that need an auditable, byte-for-byte reproducible process should test this before committing.

Finally, the install depends on external tooling: Git, uvx, and an authenticated codex CLI. Hook approval is manual and Codex may present hooks one at a time. In a locked-down environment where developers cannot approve hooks or run a local service on 127.0.0.1:48267, the setup will not complete.

TradingCodex compared with a plain Codex prompt or a notebook stack

The obvious alternative is using Codex directly with a long prompt. The difference is persistence. A prompt produces text in a conversation. TradingCodex writes structured artifacts into trading/research, trading/reports, trading/forecasts, and trading/decisions, and separates a Knowledge Wiki from Investment Brain from Decision Memory so that background reading is never mistaken for current evidence. That separation is the actual feature; the agent roster is the visible part.

A second alternative is a notebook-based research stack, where you script data pulls and store results yourself. That gives you full control over reproducibility and data sources, and it does not require Codex, uvx, or a local Django service. What it does not give you is the adversarial step: a Judgment Reviewer whose stated role is to challenge evidence and confidence. You would have to build that discipline into your own process.

A third comparison is any tool that executes trades. TradingCodex deliberately sits one step upstream. It is not competing on order routing or latency, and it should not be evaluated on those terms.

Licence, versioning and what maintenance looks like from the outside

TradingCodex is Apache-2.0, and pyproject.toml declares license-files for LICENSE and NOTICE, which means attribution notices travel with redistribution. The repository also carries a TRADEMARKS.md file, so the licence covers code while names and marks are handled separately. That is a common arrangement, but it matters if you plan to rebrand or redistribute. Nothing here is legal advice; read LICENSE, NOTICE, and TRADEMARKS.md together before shipping a derivative.

On cadence, the last push to the default branch was on 2026-07-24, and the most recent releases are v2.1.3, v2.1.2, and v2.1.1, all dated 2026-07-24. Three releases in one day suggests a fast patch cycle around a single milestone rather than steady weekly movement. The repository is not archived.

Upgrade cost is low by design. Installation runs through uvx --refresh --from tradingcodex, so upgrading means re-running the attach and doctor steps rather than managing a virtualenv by hand. The declared Python range is 3.11 to 3.14, and Django is pinned to the 5.2 series, so a Django 6 migration would be a breaking event for this project. pyarrow is pinned exactly at 25.0.0, which is the kind of pin that can collide with other tools in a shared environment.

Editorial conclusion

Adopt TradingCodex if you already run the Codex CLI and want research artifacts that persist as files rather than chat history. Skip it if you want automated order execution or a charting terminal: the README states there is no execution agent, and the project publishes no TradingView integration. Before trusting it, run ./tcx doctor in a fresh workspace and read the generated trading/research and decisions folders to confirm the provenance trail meets your standard.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. monarchjuno/tradingcodex on GitHub
3. Project website
4. README
5. Releases