ibkr

Updating

Updated: 2026-05-26 22:02 CEST

Four things can affect data freshness: the binary (ibkr itself), the Claude Desktop MCPB when installed through Desktop Extensions, the S&P 500 constituent list the breadth indicator uses, and the embedded official market calendars. They update independently because they have different sources and cadences.

Updating the binary — ibkr update

Once you're on v1.0.0 or later, the next upgrade is one command:

ibkr update            # fetch latest, prompt to restart daemon

The CLI checks the GitHub /releases/latest endpoint, matches your OS/arch against the published tarballs, verifies the **PGP signature on SHA256SUMS** against the maintainer's public key embedded in your current ibkr binary, then SHA-verifies the tarball and atomically replaces ~/.local/bin/ibkr. The prior binary is stashed as ~/.local/bin/ibkr.bak for one-step rollback (mv ~/.local/bin/ibkr.bak ~/.local/bin/ibkr).

A running daemon is asked to restart at the end — the daemon picks up the new binary on its next autospawn.

Release integrity

From v1.0.0 onward, every release ships SHA256SUMS.asc — a PGP detached signature over SHA256SUMS, produced by the maintainer's Ed25519 key (fingerprint D984 26D4 8FED 85EF A339 0469 4D92 2A4F 922B 7D7D). The public key is embedded in every ibkr binary, so ibkr update verifies the next release using a key your already-installed binary carries — no network bootstrap an attacker could swap.

Releases that publish an MCP Bundle include both ibkr-vX.Y.Z.mcpb and the stable latest-download asset ibkr.mcpb in SHA256SUMS. The MCP Registry publish artifact also records the versioned MCPB file's SHA-256 in server.json as fileSha256.

The MCPB container itself is not yet code-signed. Treat MCPB release integrity as signed-checksum and registry-hash based unless mcpb verify ibkr-vX.Y.Z.mcpb succeeds for a future release.

ibkr update refuses any release missing the signature, and any release whose signature does not verify against the embedded key. There is no --insecure flag. If you ever need to debug a verification failure, the underlying error is printed verbatim and the manual verification steps are in SECURITY.md → Release integrity.

Headless / scripted use

In non-interactive contexts (cron, systemd timers, CI, stdin-redirected shells) the [Y/n] prompt would block. Pass an explicit restart decision:

ibkr update --restart        # auto-restart daemon
ibkr update --no-restart     # don't restart; print "restart pending" hint

Running ibkr update from a non-TTY without either flag exits non-zero with ambiguous in non-interactive mode and does not install. This is deliberate — silent default-to-N would be a footgun for systemd timers expecting auto-restart.

Other flags

ibkr update --check          # dry-run: print "would install vX.Y.Z", exit 0
ibkr update --force          # re-install latest even if same version (corrupt-binary recovery)

--check exits 0 whether or not an update is available — only fetch failures exit non-zero. So ibkr update --check && ibkr update is the idiomatic confirm-then-install pattern.

Pre-v1.0.0 binaries

ibkr update only exists from v1.0.0 onward. Earlier installs upgrade once manually (download the tarball from releases, extract, run make install), then carry forward with ibkr update.

Updating Claude Desktop MCPB installs

Claude Desktop MCPB installs carry their own embedded ibkr binary. ibkr update updates shell-managed installs such as ~/.local/bin/ibkr; it does not replace a binary embedded inside Claude Desktop's extension store.

To update a Claude Desktop MCPB install, download the latest bundle and reinstall it in Claude Desktop:

<https://github.com/osauer/ibkr/releases/latest/download/ibkr.mcpb>

After reinstalling, fully quit Claude Desktop and reopen it so it respawns the MCP server from the updated bundle.

Updating the S&P 500 list — automatic

The daemon refreshes the constituent list from Wikipedia's "List of S&P 500 companies" on three triggers, all converging on one shared fetch:

On success the new list is written to ~/.cache/ibkr/spx-members/sp500-members.json and pushed into the breadth engine. On any failure (network, parse error, count outside the 450–520 sanity band), the daemon keeps using whatever was loaded — breadth never goes silent.

Pinning the list (regulated traders, reproducibility audits, air-gapped)

Some users need a frozen membership list. Two override layers, with symmetric semantics:

Persistent (TOML config):

[spx]
members_auto_refresh = false

Ad-hoc (env var, overrides TOML):

IBKR_SPX_MEMBERS_AUTO_REFRESH=0 ibkr daemon   # force off
IBKR_SPX_MEMBERS_AUTO_REFRESH=1 ibkr daemon   # force on (even if TOML says off)

When pinned, ibkr status shows the reason — refresh:disabled (env) vs refresh:disabled (config) — so a confused user knows which knob to flip.

Status row

ibkr status always carries a one-line summary of the members source and refresh health:

Members  cache:2026-05-22  count:503                            # healthy
Members  embedded:2026-05-22  count:503  refresh:parse_failed   # silent rot (Wikipedia changed HTML)
Members  embedded:2026-05-22  count:503  refresh:network_failed # offline / DNS down

The cache:DATE vs embedded:DATE source token tells you whether the in-process list is from the auto-refresh path or the binary's compiled-in fallback. The bracketed refresh:<state> suffix appears only when something needs attention.

Updating market calendars - binary release

Market calendars are embedded official exchange schedules in this first release. The supported calendars are US cash equities, US listed options regular sessions, and German Xetra cash equities. They do not cold-start, hit a network cache, or apply an IBKR-specific overlay at runtime; the official exchange calendar is the binding source for open/closed/holiday/early-close context.

Each response includes coverage_start and coverage_end. Queries outside embedded coverage return state: "unknown" rather than guessing from weekdays. The CLI/MCP days horizon is capped at 400 calendar days, which covers the practical risk-manager lookahead for next-session, long-weekend, year-end, and next-year holiday checks while keeping responses bounded.

Calendar updates arrive with normal ibkr binary updates. If a supported exchange publishes an unscheduled closure or changes a future holiday after your installed binary was built, update the binary once a release carrying the refreshed calendar is available.

Where state lives

All under $XDG_CACHE_HOME / $XDG_CONFIG_HOME when set; the paths above are the fallback.

Reference