DEV Community: Vinh Nguyen

Your automation is not logged out: a missing `--cdp` flag started a second Chrome

Vinh Nguyen — Wed, 02 Sep 2026 00:08:08 +0000

A scheduled job of mine drives a real Chrome profile that stays signed in to DEV, because the API can read comments but cannot create them. One run came back with the dashboard replaced by the sign-in page: the log said it had opened https://dev.to/dashboard, and what it actually landed on was https://dev.to/magic_links/new, with zero links to my own profile anywhere in the DOM.

The profile itself was fine. A probe against the debugging port at the same moment returned a live Chrome, and the dashboard fetched through that port rendered the account's own identity links normally. Two browsers, same machine, same minute, opposite answers.

The three things worth checking first, and why they miss

The session expired. That is the reflex, and it is also the one that makes you re-authenticate for no reason and burn the logged-in state you were trying to protect.

Cookies got cleared by a Chrome update. Same family, same cost if you act on it.

The debug port died and the tool fell back to something else. This one is close enough to be dangerous, because it names the right layer — which browser am I attached to — and then picks the wrong cause inside it.

Where it actually goes wrong

It is one argument.

agent-browser attaches to an already-running Chrome when you pass --cdp <port>. Leave the flag off and it starts its own browser, with its own empty profile directory, and drives that one instead. Everything downstream still works — it navigates, waits, evaluates, returns a page. It just does all of that in a browser that has never logged in to anything.

So the automation is not looking at an expired session. It is looking at a different browser's logged-out session, and reporting it in exactly the shape a real logout would take.

The two failure modes do not look alike, and that is the trap

Here is what I measured today, on Chrome 152.0.7977.65 with the current npx build.

Pass the flag, but point it at a port nothing is listening on:

npx -y agent-browser open "https://dev.to/dashboard" --cdp 49299
echo $?

✗ All CDP discovery methods failed for 127.0.0.1:49299: /json/version: Failed to
connect to CDP at 127.0.0.1:49299 ...; WebSocket: WebSocket connect failed at
ws://127.0.0.1:49299/devtools/browser: IO error: Connection refused (os error 61)

Exit code 1. Nothing launched. This branch cannot hurt you, because it stops.

Now leave the flag off entirely:

npx -y agent-browser open "https://dev.to/dashboard"
echo $?

[agent-browser] launched browser
✓
  https://dev.to/magic_links/new

Exit code 0. That is a success by every check a wrapper script is likely to run.

The inversion is the whole problem. A dead port announces itself and halts. A missing argument — the case you will actually hit, since nobody types a dead port on purpose — succeeds quietly and hands back a browser that is not yours. And because the symptom presents as "suddenly logged out", the instinct is to go hunting for a dead port, which is the one branch that would have told you out loud.

The tell is that single line, launched browser. If it shows up, or relaunched browser does, you are not on your profile, whatever the rest of the run reports.

A port that answers is not a profile that matches

The natural hardening step is to probe the port before running anything:

curl -s http://127.0.0.1:49224/json/version

I do run that and it is worth running, but it does not prove what it appears to prove. It establishes that some Chrome is listening there. It says nothing about whether that Chrome is holding your session.

The check that settles it reads the profile directory off the process bound to that port:

ps aux | grep "[C]hrome" | grep -- "--remote-debugging-port=49224" \
  | grep -o -- "--user-data-dir=[^ ]*"

Today that returns the profile directory I expect, the port reports Chrome/152.0.7977.65, and the dashboard renders 27 links to my own account. Those three together are an identity. Any one of them on its own is not.

The variant that costs more than a wasted run

connect deserves separate care, because it takes the port as a positional argument, which reads as though the port has already been supplied:

npx -y agent-browser connect 49224     # not enough

It still wants --cdp. Without it, one run of mine replaced the live Chrome with a scratch profile and the real window was gone. A separate run of the same command printed relaunched browser while the port kept answering normally — which is where a live port sitting in front of the wrong profile comes from.

Pass --cdp <port> on every command, including the one that already has the port sitting in its arguments.

What this is bounded to

Measured on macOS with Chrome 152.0.7977.65 and the npx build of agent-browser as of today. The dead-port and missing-flag branches were both re-run this morning and behaved as described above; the connect behaviour is from two earlier runs and I have not re-triggered it, for the obvious reason that reproducing it costs a live session.

Exit codes and log strings are properties of one CLI at one version, so treat them as a shape to look for rather than constants to assert on. What generalises is narrower than the tool: if a browser automation library is capable of starting a browser for you, then a page that says you are signed out is telling you the truth about the browser you got, which is not necessarily the browser you asked for.

A LaunchAgent gets `Operation not permitted` for `~/Documents` while Terminal works

Vinh Nguyen — Wed, 26 Aug 2026 00:22:04 +0000

The same zsh script could list ~/Documents when I ran it in Terminal. Started as a LaunchAgent, it failed with:

ls: /Users/administrator/Documents: Operation not permitted

The LaunchAgent had the same user ID, the same $HOME, and the same script. That combination makes this look like a Unix permission problem. In this test it was not. The useful discriminator was the launch context: access succeeded from Terminal, failed from launchd, and still succeeded for a path outside the protected folder.

I reproduced this on macOS 15.6.1 (Darwin 24.6.0) with a LaunchAgent in gui/501. The probe was removed after the test.

Why `chmod` is the wrong first check

The obvious suspects were file ownership, a wrong home directory, or a job running as another user. The probe printed those facts before touching the files:

#!/bin/zsh

print -- "user=$(id -un) uid=$(id -u)"
print -- "home=$HOME pwd=$PWD"

/bin/ls "$HOME/Documents" 2>&1 | /usr/bin/head -5
/bin/cat "$HOME/Documents/vinh/working/CLAUDE.md" 2>&1 | /usr/bin/head -1

# Negative control: outside Documents
/bin/ls "$HOME/.pf004" 2>&1 | /usr/bin/head -5

The two runs produced this difference:

Check	Terminal	LaunchAgent in `gui/501`
User / uid	`administrator` / `501`	`administrator` / `501`
`$HOME`	`/Users/administrator`	`/Users/administrator`
`ls ~/Documents`	Listed entries	`Operation not permitted`
`cat` inside `~/Documents`	Read the file	`Operation not permitted`
`ls ~/.pf004`	Listed entries	Listed entries

The working directory differed, but the script used absolute paths under $HOME, so PWD=/ did not explain the denial. The negative control mattered more: the LaunchAgent could read another directory owned by the same user. Changing ownership or mode bits would not explain why only the launch context changed the result.

The owning layer is the privacy context

On this machine, the access decision was attached to how the process was launched, not just to uid 501. Terminal had a privacy context that allowed access to the user's Documents folder. The process started by launchd did not inherit that access.

That is why these observations can all be true at once:

id -u reports the expected user.
$HOME points to the expected home directory.
Ordinary files elsewhere under that home directory are readable.
A read under ~/Documents returns Operation not permitted.

The smallest diagnostic is therefore not another chmod. Run one identical read from the interactive application and from the scheduled process, then add a control path outside Desktop, Documents, or Downloads. If the user and path are correct, the control succeeds, and only the protected folder fails, investigate the macOS privacy context of the scheduled process.

A pipeline can hide the denial

My first probe contained this line:

/bin/ls "$HOME/Documents" 2>&1 | /usr/bin/head -5
print -- "status=$?"

It printed Operation not permitted and then printed status=0.

In zsh, the default status of a pipeline is the status of its last command. head successfully printed the error text, so the pipeline looked successful even though ls failed. This is enough to turn a visible privacy denial into missing downstream data.

For a diagnostic script, enable pipeline failure before the probe:

set -o pipefail

/bin/ls "$HOME/Documents" 2>&1 | /usr/bin/head -5
print -- "status=$?"

I checked the behavior with a minimal control: /usr/bin/false | /usr/bin/head -1 returned 0 by default and 1 with pipefail enabled. In a larger job, capture and handle the status immediately rather than letting another command overwrite $?.

What to change in an unattended job

If the job does not need a protected folder, move its required inputs and state to an unprotected application directory. The negative-control path under ~/.pf004 was readable from both launch contexts in this test.

If the job must read Documents, treat that as a separate permission requirement and test it from the actual LaunchAgent. A successful Terminal run is not proof that the scheduled process has the same access. I did not test Full Disk Access, a system LaunchDaemon, Desktop, or Downloads, so this result does not establish how those configurations behave.

The practical rule is narrow: same uid and same $HOME do not make Terminal and a LaunchAgent equivalent readers of ~/Documents. Compare the launch contexts, keep an outside-path negative control, and make the pipeline report the command that actually failed.

The DEV API drops the "published" field on the endpoint you would check it from

Vinh Nguyen — Sun, 23 Aug 2026 00:03:24 +0000

If you script your posting to dev.to, the obvious way to confirm a post went live is to read published back from the API. On the endpoint you would naturally use for that, the field is not false and it is not null. It is not in the response at all, so article.get("published") hands you None and your script decides a live article is still a draft.

The reliable check is simpler: use an unauthenticated GET /api/articles/{id} returning HTTP 200 as proof that a stranger can read the article. Use the author-scoped collections when you need to distinguish drafts from published posts.

Everything below was measured on 2026-08-21 against dev.to with API v1, on my own account, with three published articles and one draft.

One article, two shapes

The author-scoped list endpoint carries the field:

curl -s "https://dev.to/api/articles/me/published?per_page=1" \
  -H "api-key: $DEVTO_KEY" \
  -H "accept: application/vnd.forem.api-v1+json" \
| python3 -c 'import sys,json;a=json.load(sys.stdin)[0];print(a["id"], a["published"], a["published_at"])'

4408696 True 2026-08-16T07:13:13.534Z

The single-article endpoint, same key, same article id, does not:

curl -s "https://dev.to/api/articles/4408696" \
  -H "api-key: $DEVTO_KEY" \
  -H "accept: application/vnd.forem.api-v1+json" \
| python3 -c 'import sys,json;a=json.load(sys.stdin);print("published" in a, a.get("published_at"))'

False 2026-08-16T07:13:13Z

I ran that request three ways, with the api-key header, without it, and without the vendor accept header, and "published" in a was False every time. So this is not a permissions difference between an author and a stranger. The key does not change it.

The write path is the same shape. A PUT /api/articles/{id} returned HTTP 200 and a body with no published key either, even though published is a field I had just sent in the request.

Which leaves the two ways a script gets this wrong. article["published"] raises KeyError on a successful publish, and article.get("published") quietly reports a public article as unpublished, which is worse, because that branch usually retries.

Why

published is an input. You send it on POST /api/articles and on PUT /api/articles/{id} to move a draft to public. The collections under /api/articles/me/* are author-scoped, so they describe your article the way its owner sees it and echo the flag back.

GET /api/articles/{id} is a different representation. It serves the article the way an anonymous reader receives it, and in that view there is no publication state to report, because an article you can fetch there is by definition one that is published.

The negative control

That last sentence is the part worth testing rather than assuming, so I asked the endpoint for something the public cannot see. I created a draft with "published": false, took its id from GET /api/articles/me/unpublished, and requested it directly.

curl -s -o /dev/null -w "%{http_code}\n" "https://dev.to/api/articles/4449977"

Then the same request with my own key, for my own draft:

curl -s -w " HTTP %{http_code}\n" "https://dev.to/api/articles/4449977" \
  -H "api-key: $DEVTO_KEY" \
  -H "accept: application/vnd.forem.api-v1+json"

{"error":"not found","status":404} HTTP 404

My draft, my key, still 404. The endpoint has nothing to say about anything that is not public, which is why the flag is missing rather than false.

Check the thing you actually care about

The 404 is the useful half. It turns the presence of a response into the signal:

code=$(curl -s -o /dev/null -w "%{http_code}" "https://dev.to/api/articles/$ID")
[ "$code" = "200" ] || { echo "not public: HTTP $code"; exit 1; }

An unauthenticated 200 means a stranger can read the article. That is the property you were after when you went looking for published, and it is a stronger check than a boolean echoed back from your own request, because nothing about it depends on your credentials. Take the timestamp from published_at on that same response.

If you need the other direction, the list of what is still a draft, ask the author-scoped endpoint. GET /api/articles/me/unpublished returned published: false for my draft and me/published returns true. Those endpoints answer the ownership question. The id endpoint does not, and the missing key is the only notice you get.

Where this was tested

dev.to itself, API v1, with the accept: application/vnd.forem.api-v1+json header, on 2026-08-21. I did not test a self-hosted Forem instance, an organization article, or a scheduled post, and a self-hosted instance can be several versions behind. If the field starts appearing on the id endpoint later, the unauthenticated 200 check keeps working regardless, which is why my own publishing script gates on that instead of on the flag.

If you run the same check against a self-hosted Forem or a scheduled post, I would be interested in the response shape and Forem version. Those are the two cases I have not tested.

If your saved numbers drift, check the scroll wheel before the database

Vinh Nguyen — Sun, 16 Aug 2026 07:13:13 +0000

Someone built a small clinical app with AI coding tools. You type a child's weight and length, and it returns Z-scores against the growth reference. It worked. Then users started reporting that saved values came back slightly higher than what they had entered.

Small drift. A few tenths, sometimes a whole unit. The kind of number that looks like floating point, or a unit conversion, or a rounding rule applied twice.

Three days went into finding it. Here is where they went, because the wrong turns are the useful part.

Three clean layers

The obvious suspects were checked in the obvious order.

Rounding. The display rounds to one decimal, the store keeps full precision. Read back, compared, no discrepancy.

The conversion before the write. Values pass through a normalisation step on the way to storage. It was checked against its own inputs and outputs. Clean.

Field binding. The classic: weight bound to the length field, or two inputs sharing one piece of state. Also clean.

All three were clean, which is exactly why the search kept circling them. When a layer is innocent you do not cross it off, you assume you checked it badly and go around again.

The value was already wrong

The mistake was in the framing, not in any of those checks. Every one of them asked "what happens to the number on its way to storage". Nobody asked what the number was when the save handler received it.

It was already wrong.

An <input type="number"> that has focus consumes the wheel event, and the browser increments or decrements the value by one step per notch. This is standard, specified behaviour and it has been in browsers forever.

Now look at the layout in the screenshot. The results table sits directly below the form. That is a perfectly reasonable design — you enter measurements, you read the interpretation underneath. It also means that after typing a weight, the natural next action is to scroll down to read the Z-scores, and the cursor is still sitting in the weight field.

Every scroll edits the value that was just typed.

The drift stays small because a couple of notches is a couple of steps, which is why it reads like a rounding artefact instead of an input bug. And it does not reproduce when a developer tests it, because a developer types a value, tabs out, and clicks the button. Nobody scrolls with the cursor parked in the field except a real user reading a result that happens to be below the fold.

The fix is one line

Drop focus when the wheel fires:

<input
  type="number"
  onWheel={(e) => e.currentTarget.blur()}
  ...
/>

Or stop using type="number" for a value that is not really a spinner:

<input
  type="text"
  inputMode="decimal"
  ...
/>

The second keeps the numeric keypad on mobile, which is usually the only reason type="number" was chosen in the first place. It also gives up the browser's built-in numeric validation, so whatever validation you were leaning on has to become explicit.

Pick either. The interesting part is not the fix.

Nobody reviews code nobody asked for

The person debugging this reviewed their code carefully. They just reviewed the code they had asked for.

Scroll-to-increment was never requested. It is not a line anyone wrote. It arrived as a property of a default that got selected while generating a form — defensible in isolation, never specified, never reviewed, and invisible until a real hand touches a real mouse.

This is the failure mode I keep meeting in applications assembled with AI coding tools, and it is not "the AI writes buggy code". The generated code was fine. Individually every choice in it was reasonable. The gap is that a specification never existed, so there is no document against which any of it is wrong, and no reviewer whose job it was to notice a behaviour nobody ordered.

The bug report language made it worse, as it usually does. "The saved value changed" names a layer. It sends you to persistence, and persistence is where three days went. A report that said "the number changes while I am reading the results" would have been solved in ten minutes — but users do not report mechanisms, they report the last thing they saw.

The part that generalises

When you get a report that a stored value disagrees with what the user believes they entered, the search space is larger than the write path. Something upstream may be editing it: a wheel event, an autofill, a controlled component reformatting on re-render, an event handler firing on a parent.

A cheap way to cut the search in half: log the value at the moment the handler receives it. If it is already wrong there, every layer below is innocent and you stop re-reading them.

This is the difference between a prototype that works and a product that survives its users. The code was fine. The product was not.

I am curious how common the split is: when a stored value disagreed with what your users thought they entered, how often did it turn out to be the write path, and how often was it something upstream of it?

Exporting ANTHROPIC_BASE_URL does not reach the Claude Code panel in VSCode

Vinh Nguyen — Sat, 15 Aug 2026 16:56:49 +0000

export ANTHROPIC_BASE_URL=http://127.0.0.1:20128 in your shell routes the claude CLI to a local endpoint. Open the Claude Code panel in VSCode in the same project and it still talks to Anthropic directly. The two live on different environment surfaces, and that is the whole problem.

Why the shell variable does not carry over

The CLI reads the environment of the process you started it from. The VSCode panel does not: the extension spawns its agent process from the VSCode window process, so its environment is whatever VSCode itself was started with — the desktop/login environment, not the shell you typed export into five seconds ago.

Two consequences that bite in opposite directions:

Export in a terminal, then open the panel: nothing happens. The panel never saw the variable.
Launch VSCode from that terminal instead, so it inherits the vars: now every workspace in that window is routed, including the ones where you wanted the default Anthropic connection.

The escape hatch the extension gives you is a settings key, claudeCode.environmentVariables, which is a list of {name, value} pairs injected into the agent process. You can check what your panel actually sees right now — this runs anywhere jq does:

# macOS
S="$HOME/Library/Application Support/Code/User/settings.json"
# Linux:   S="$HOME/.config/Code/User/settings.json"
# Windows: S="$APPDATA/Code/User/settings.json"

jq -r '.["claudeCode.environmentVariables"] // []
  | if length == 0
    then "panel env: (none set) -> extension inherits the VSCode process env"
    else (.[] | "\(.name)=\(if .name|test("TOKEN|KEY") then "***" else .value end)")
    end' "$S"

On a machine that has never been switched, that prints the (none set) line. That is the honest answer to "why is my panel ignoring the variable".

Editing that key by hand is where it goes wrong

claudeCode.environmentVariables is a plain array in your user settings.json, and hand-editing it has three failure modes I hit before writing anything:

It has machine scope. It is not per-workspace. Turn routing on for one project and every VSCode window on that machine is routed.
Turning it off means deleting entries, not flipping a flag. Leave ANTHROPIC_BASE_URL behind while removing the token and the panel points at a router with no credential.
It shares the array with unrelated variables. Anything else you put there — proxy settings, a NODE_EXTRA_CA_CERTS — is one careless overwrite away from gone.

So the toolkit I ended up with treats the array as partly owned. It manages exactly six names:

ANTHROPIC_BASE_URL
ANTHROPIC_AUTH_TOKEN
ANTHROPIC_API_KEY
ANTHROPIC_MODEL
ANTHROPIC_SMALL_FAST_MODEL
CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC

Entries whose name is not on that list are read, kept aside, and written back untouched. Before any write it copies settings.json to settings.json.bak-claude-router, and if serialisation throws it restores the backup and exits non-zero rather than leaving you with half a settings file.

& "$env:USERPROFILE\.claude\9router\vscode-switch.ps1" on      # inject the six
& "$env:USERPROFILE\.claude\9router\vscode-switch.ps1" status  # print base URL + model, never the token
& "$env:USERPROFILE\.claude\9router\vscode-switch.ps1" off     # remove only the six

on and off need a Developer: Reload Window afterwards — the agent process reads its environment once at spawn.

The terminal side keeps the opposite property

For the CLI the right scope is the narrow one, so there routing is per-process and nothing is persisted:

claude                    # default Anthropic connection
claude-9router            # same CLI, routed
claude-9router --resume   # normal Claude CLI arguments pass through

claude-9router sets the variables inside its own process, unsets ANTHROPIC_API_KEY so a leftover key cannot win over the router token, then execs claude. Close the window and the routing is gone. Nothing in ~/.claude is rewritten.

That asymmetry is deliberate and it is the actual design decision: the terminal gets process scope because a shell is cheap to start, the panel gets machine scope with an explicit on/off because the extension gives no narrower hook. Cost of the second: you cannot have one routed window and one direct window at the same time. If you need both, use the panel for one and claude-9router in a terminal for the other.

Configuration and what it does not do

The endpoint is a 9Router instance, whose Anthropic-compatible /v1/messages fronts a long list of providers. The toolkit hard-codes none of them; it reads a gitignored local file:

{
  "baseUrl": "http://127.0.0.1:20128",
  "authToken": "your-9router-api-key",
  "mainModel": "provider/model-id",
  "smallFastModel": "provider/smaller-model-id"
}

Limits, stated plainly:

Windows only. PowerShell 5.1+, and the VSCode settings path is the Windows one. macOS and Linux are not supported today.
Routing the client does not make the model Claude. The Claude Code UI is a shell; the answers come from whatever provider you selected in 9Router. Tool use, streaming, vision and prompt caching vary by provider — test the exact model before trusting it.
Provider terms are yours to check. Some subscriptions and OAuth sessions are not licensed for proxy or router use, and accounts do get restricted for it. Route only accounts you are authorised to route.
No benchmark numbers here because I have not measured any. The repo does not claim latency or cost figures either.

Repo, and where a second pair of hands helps

Code, tests and setup guide: https://github.com/vinhnguyenthanhdn/claude-router (MIT).

The open gap is the platform one: the Windows paths are the only ones implemented and tested, and porting is work I have not done. Three issues are scoped and open:

If you only want to confirm the diagnosis rather than write code: run the jq snippet above on your machine and tell me what your panel is actually inheriting. That answer is useful on its own.

How I verify a crypto backtest is real: trade-for-trade parity, bit-for-bit data, and a look-ahead test with teeth

Vinh Nguyen — Sun, 09 Aug 2026 03:30:16 +0000

Most public trading repos show you a backtest with a nice equity curve. The hard part isn't producing the curve — it's knowing whether the curve is real. So I spent most of my time building the machinery that decides that, and I've open-sourced it: github.com/vinhnguyenthanhdn/ai-crypto

Python 3.10+, MIT. No real orders are ever placed; every execution path is simulated.

Implementation parity, verified trade-for-trade

The single biggest source of false confidence in a backtest is that the thing you tested and the thing you run are not the same program.

So the research reference engines and the production strategy cores are written independently, then reconciled against each other: 963/963, 515/515 and 1,079/1,079 trades matched with zero mismatches, with equity agreeing to 8 decimal places.

That reconciliation runs as a check, not as a one-off claim.

Data verified bit-for-bit

9 years of market history: 942,025 5-minute candles plus 1,508 checksum-verified derivatives archives. Every artifact records a SHA-256 dataset hash, so any result can be tied back to the exact bytes it was computed from.

The price cache was reconciled against the venue API across 3,277 days and matched bit-for-bit.

A look-ahead test that provably has teeth

It's easy to write a look-ahead check that passes because it can't detect anything.

So I deliberately injected look-ahead into a passing contract and measured what happened: training return inflated from +563% to +4,201%. The test can see the bug when the bug is there. That's the part most look-ahead checks never demonstrate.

Costs are verified the same way — measured at −0.29985% on a flat round trip against a stated 0.30%, confirming they're charged exactly once.

Accelerated paper replay through the real lifecycle

3,277 days of history driven through the production SQLite state store, position sizing and accounting. Only the market clock is simulated — everything else is the code that runs live.

Result: 77 ENTRY / 77 EXIT / 77 ledger rows, zero orphaned entries, zero positions left open.

Event-sourced state with full lineage

Append-only event_log and feature_snapshot, plus an idempotent equity_ledger keyed by trade ID.
Position and risk computed from real equity, not notional assumptions.
Every feature snapshot records source exchange, market type, symbol, timeframe, transformation version and the strategy package that consumed it — so any logged decision can be reconstructed from raw candle to logged trade.
Atomic run locking via SQLite BEGIN IMMEDIATE with owner token and heartbeat; a dead process's lease is reclaimed immediately instead of waiting out a stale timeout.
Market-data freshness is enforced: stale collector ticks hard-fail or force a fresh fetch rather than silently reusing an old snapshot.

Costs measured instead of assumed

I sampled 4,695 order book snapshots and pulled base-tier venue fees from official sources. The real half-spread came out at 0.0077 bps, not the 5 bps my own config had assumed — my round-trip cost assumption had been about 3× too high.

Worth knowing if you're calibrating a cost hurdle from a blog post rather than from the book.

Frozen contracts and a documented search

Parameters are selected on the training split only, the contract is frozen, then validation and test are opened once. Every candidate must survive round-trip costs stressed to at least 2× base.

Under that protocol I ran 29,373 parameter configurations across ~40 strategy families, and every one of them is written up — contract, dataset range, cost assumptions, verdict — as ~100 result artifacts. Including the rejections, which is the part that's usually missing and the part that saves you re-walking a dead end.

The repo also audits itself

docs/code-audit.md splits the codebase into a research path that is independently verified and trusted, and a runtime path with confirmed defects — including a BUY threshold that is arithmetically unreachable and a look-ahead bug in the swing detector. Those are catalogued with file and line references rather than quietly patched, so you know which numbers to trust.

The same honesty applies to the headline outcome: none of the 29,373 configurations cleared the promotion gates. Median gross edge across 13,654 rejected configs is −0.021%, so it isn't a cost problem — there's nothing there to rescue. The full evidence is in the repo, and I'd rather publish that than a curve I can't defend.

Try it

python3 -m venv .venv && source .venv/bin/activate
pip install -r requirements.txt
cp .env.example .env

.venv/bin/python3 scripts/run_backtest.py        # bar-close scan
.venv/bin/python3 scripts/dashboard_server.py    # local dashboard

API keys are optional and must be read-only — the system works on public market data alone.

Contributions welcome, and if you find a hole in the methodology I'd genuinely like to hear it.

github.com/vinhnguyenthanhdn/ai-crypto