General improvements: security, correctness, performance and consolidation sweep (114 items)

.github/workflows/ci.yml

@@ -11,13 +11,13 @@ jobs:
     name: Backend Lint
     runs-on: ubuntu-latest
     steps:
-      - uses: actions/checkout@v4
+      - uses: actions/checkout@v7
 
-      - uses: astral-sh/setup-uv@v4
+      - uses: astral-sh/setup-uv@v10.0.1
         with:
           version: "latest"
 
-      - uses: actions/setup-python@v5
+      - uses: actions/setup-python@v7
         with:
           python-version: "3.12"
 
@@ -34,13 +34,13 @@ jobs:
     name: Backend Import Check
     runs-on: ubuntu-latest
     steps:
-      - uses: actions/checkout@v4
+      - uses: actions/checkout@v7
 
-      - uses: astral-sh/setup-uv@v4
+      - uses: astral-sh/setup-uv@v10.0.1
         with:
           version: "latest"
 
-      - uses: actions/setup-python@v5
+      - uses: actions/setup-python@v7
         with:
           python-version: "3.12"
 
@@ -60,13 +60,13 @@ jobs:
     name: Backend Tests
     runs-on: ubuntu-latest
     steps:
-      - uses: actions/checkout@v4
+      - uses: actions/checkout@v7
 
-      - uses: astral-sh/setup-uv@v4
+      - uses: astral-sh/setup-uv@v10.0.1
         with:
           version: "latest"
 
-      - uses: actions/setup-python@v5
+      - uses: actions/setup-python@v7
         with:
           python-version: "3.12"
 
@@ -83,11 +83,11 @@ jobs:
       run:
         working-directory: frontend
     steps:
-      - uses: actions/checkout@v4
+      - uses: actions/checkout@v7
 
-      - uses: actions/setup-node@v4
+      - uses: actions/setup-node@v7
         with:
-          node-version: "20"
+          node-version: "22"
           cache: "npm"
           cache-dependency-path: frontend/package-lock.json
 

PRIVACY.md

@@ -1,17 +1,21 @@
 # Privacy
 
 Condor is self-hosted. It runs on your machine, holds your exchange API keys,
-and places your orders. So what leaves that machine by default is the absolute
-minimum — an anonymous "this install exists" — and everything beyond that is
-opt-in. This document is the complete statement of both.
-
-**Short version:** a fresh install counts itself and nothing more. With no
-consent recorded it runs at level `ping`: a random install id, the version, and
-a periodic heartbeat — nothing about you, your users, or your trading. None of
-the usage events are sent until an admin taps "yes" on a prompt. Batches go to
-the project's collector at `https://telemetry.hummingbot.org/v1/events`, which
-is fixed in the source and cannot be pointed elsewhere. An admin can turn it
-off entirely — in Settings → Privacy, or with `CONDOR_TELEMETRY=off` in the
+and places your orders. So what leaves that machine is anonymous, allowlisted,
+and announced before it starts — and anything that is content is opt-in. This
+document is the complete statement of both.
+
+**Short version:** a fresh install counts itself: a random install id, the
+version, and a periodic heartbeat — nothing about you, your users, or your
+trading. Anonymous **usage summaries** (which features are used, what breaks,
+which models agents run) are **on by default, but only after the admin has been
+told**: Condor shows one notice — a Telegram message on boot, or a strip on the
+dashboard — saying so, with a "Got it" button and a way to turn it off. Until
+that notice has been delivered, nothing beyond the install count is recorded.
+Batches go to the project's collector at
+`https://telemetry.hummingbot.org/v1/events`, which is fixed in the source and
+cannot be pointed elsewhere. An admin can turn it off entirely — from the
+notice, in Settings → Privacy, or with `CONDOR_TELEMETRY=off` in the
 environment — and a refusal, once recorded, is honoured across upgrades.
 
 There is one other way anything can leave, and it is completely separate: you
@@ -32,17 +36,18 @@ meant to be read, not trusted.
 
 ## What is collected
 
-There are three levels. The consent prompt chooses between `ping` and `usage`
-— it has no "off" button, so ignoring it is never read as a refusal. `off` is a
-deliberate act: the admin turns reporting off in Settings → Privacy, or the
-operator sets `CONDOR_TELEMETRY=off`. You can change the answer later, in
-either direction.
+There are three levels. An install that has not answered is at `ping` until the
+admin has been shown the notice, and at `usage` from then on. `off` is a
+deliberate act: the admin presses "Turn off" on the notice or picks it in
+Settings → Privacy, or the operator sets `CONDOR_TELEMETRY=off`. Ignoring the
+notice is not a refusal — but it has been read, so it is not a secret either.
+You can change the answer later, in either direction.
 
 | Level | What it sends |
 |---|---|
-| `ping` | Only that this install exists: `install`, `heartbeat`, `version_change`, `shutdown`. **This is the default, and the floor** — the prompt has no "off" option. |
-| `usage` | The above plus the feature, reliability and agent events below. Opt-in only. |
-| `off` | Nothing, ever. The emitter is a no-op — no install id is created, nothing is buffered, nothing is written, nothing is sent. Reached by an admin turning reporting off in Settings → Privacy, or by `CONDOR_TELEMETRY=off` in the environment. |
+| `ping` | Only that this install exists: `install`, `heartbeat`, `version_change`, `shutdown`. What an install sends **before the notice has reached the admin**, and what "Only count my install" in Settings keeps it at. |
+| `usage` | The above plus the feature, reliability and agent events below. **The default once the notice has been shown**; opt out at any time. |
+| `off` | Nothing, ever. The emitter is a no-op — no install id is created, nothing is buffered, nothing is written, nothing is sent. Reached by "Turn off" on the notice, by an admin turning reporting off in Settings → Privacy, or by `CONDOR_TELEMETRY=off` in the environment. |
 
 Every batch carries one context block describing the *deployment*, not you:
 
@@ -120,8 +125,9 @@ per-install, the same person on two installs produces two unrelated hashes.
 
 ## Where it goes
 
-At the default `ping` level, only the four adoption events and the envelope
-above. Everything else needs an explicit opt-in.
+Before the notice has been shown, and at `ping`, only the four adoption events
+and the envelope above. The usage events follow once the admin has been told,
+unless they turned it off.
 
 Batches are POSTed to `https://telemetry.hummingbot.org/v1/events`.
 That address is compiled into
@@ -144,37 +150,40 @@ cat .condor/telemetry/outbox.jsonl | jq .
 
 ## How to change it — or turn it off entirely
 
-Install counting (`ping`) is the floor for an install that has *not* answered:
-it is not an option on the consent prompt, because an ignored prompt must not be
-read as a refusal and the project needs an honest count of installs to know what
-to support. A refusal, though, is a different thing from silence — an admin who
-says no is obeyed, and that answer is written to `config.yml`, so it keeps
-holding after an upgrade. To check what your install is doing:
+The notice is the moment usage summaries begin for an install that has not
+answered, and it is recorded as `noticed_at` in `config.yml` only once it has
+actually been delivered — a Telegram message that failed to send, or a dashboard
+nobody opened, turns nothing on. A refusal is a different thing from silence —
+an admin who says no is obeyed, and that answer is written to `config.yml`, so
+it keeps holding after an upgrade; the notice never overrides it, nor an install
+that chose "Only count my install". To check what your install is doing:
 
 ```bash
-# The authoritative answer. Prints "ping" on a default install, and
-# "off" when CONDOR_TELEMETRY=off is set or the admin turned reporting off.
+# The authoritative answer. Prints "ping" before the notice has been shown,
+# "usage" after it, and "off" when CONDOR_TELEMETRY=off is set or the admin
+# turned reporting off.
 uv run python -c "from condor.telemetry import consent; print(consent.level())"
 ```
 
 Three ways to control it, in order of precedence:
 
 1. **Environment** — `CONDOR_TELEMETRY=off` in your `.env`. The one full kill
-   switch: it overrides everything, suppresses the prompt, and is the right
+   switch: it overrides everything, suppresses the notice, and is the right
    answer for an install that must send nothing at all.
 2. **The dashboard** — Settings → Privacy, which every seat can read and only
    the admin can change
-   (`GET`/`PUT /api/v1/settings/telemetry?level=ping|usage|off`). This is also
-   where an install that runs without Telegram is asked in the first place,
-   since it has no bot to be asked through. Choosing `off` here records a
-   refusal, which is the durable form of the kill switch: it is stored rather
-   than read from the environment of one process.
+   (`GET`/`PUT /api/v1/settings/telemetry?level=ping|usage|off`). An install
+   that runs without Telegram is shown the notice as a strip across the top of
+   the dashboard instead, since it has no bot to be told through. Choosing
+   `off` here — or "Turn off" on the notice — records a refusal, which is the
+   durable form of the kill switch: it is stored rather than read from the
+   environment of one process.
 3. **`config.yml`** — edit the `telemetry` section directly:
 
    ```yaml
    telemetry:
      consent: granted   # or `denied`, which forces level `off`
-     level: ping
+     level: ping        # or `usage`
    ```
 
 Downgrading from `usage` to `ping`, and turning reporting off, are both a
@@ -345,7 +354,8 @@ Always, which nobody but that user can do for them.
 ## Changes to this document
 
 Adding anything to the collected list requires a change to `schema.py`, a change
-to this file, and re-asking for consent. In particular, adding trading pairs
+to this file, and a new notice to every install that has not turned reporting
+off. In particular, adding trading pairs
 would make positions inferable from timing and must not be done quietly.
 
 The same applies to sharing, in its own terms. Sending anything a user has not

README.md

@@ -12,9 +12,10 @@ A Telegram bot for monitoring and trading with Hummingbot via the **Hummingbot A
 >
 > Full walkthrough: [Securing Condor and Hummingbot API with Tailscale](https://hummingbot.org/blog/posts/securing-condor-and-hummingbot-api-with-tailscale/) · [Hummingbot API Tailscale guide](https://hummingbot.org/hummingbot-api/tailscale/)
 
-> **Privacy:** Condor counts installs anonymously — a random id, the version,
-> and a heartbeat; nothing about you or your trading. Everything beyond that is
-> **opt-in** from the one prompt it sends on first boot, and
+> **Privacy:** Condor sends anonymous usage stats — a random id, the version,
+> which features get used and what breaks; nothing about you or your trading.
+> Usage summaries start only after the admin has been shown a notice saying so,
+> they can be turned off from that notice or Settings → Privacy, and
 > `CONDOR_TELEMETRY=off` silences telemetry entirely. Your conversations are
 > never part of that: the only way one leaves is if you press Share on it and
 > confirm the redacted transcript, which `CONDOR_SHARING=off` disables outright.

agents/_defaults/core_rules.md

@@ -17,6 +17,16 @@
   instead of reimplementing what it already does by hand.
 - **Short tool chains.** 1–5 calls per response or tick. One skill-driven flow
   beats a long chain of raw calls that reconstructs what the playbook says.
-- **Confirm before you move money.** Orders, swaps, LP mutations and anything
-  destructive get confirmed with the user first. The rule is the guard, not the
-  prompt you happen to be in.
+- **Never end a turn with a background task outstanding.** If you launch a Bash
+  command with `run_in_background`, collect its output before you answer. Prefer
+  a foreground command with a generous `timeout` — a task that finishes after
+  your turn ends will interrupt the user's *next* question with stale work.
+- **Confirm before you move money — when there is someone to confirm with.**
+  In a chat, or any seat with a human in it, orders, swaps, LP mutations and
+  anything destructive get confirmed with the user first.
+  In an unattended loop the approval already happened: the user approved the
+  launch, with its capital and its risk limits, and the runtime checks every
+  call against that envelope before it runs. There, act inside your limits
+  without asking — a trade held for a confirmation nobody is there to give is
+  not caution, it is a loop that does not work. Either way the guard is the
+  runtime, never the wording of the prompt you happen to be in.

agents/_defaults/shutdown.md

@@ -10,7 +10,9 @@ any orphan positions the policy says to close. You are the best-effort cleanup p
 running on top of that guaranteed floor. Now:
 
 - If any position is spot dust worth less than ~$5, leave it — not worth the fees.
-- Cancel any stray Gateway / LP / resting orders you can find for this session.
+- Cancel any stray resting orders (CEX or CLOB DEX — `hyperliquid`, `xrpl` and the like
+  are plain Hummingbot connectors, not Gateway) and close any leftover Gateway LP
+  position (AMM/CLMM pools) you can find for this session.
 - If any position that should be closed is still open, close it (stop its executor
   with keep_position off, or place a reduce-only order).
 - Notify the owner via `send_notification` with the final realized PnL and a short

agents/_shared/skills/dca_into_position/SKILL.md

@@ -31,6 +31,10 @@ get_prices(connector_name="binance_perpetual", trading_pairs=["BTC-USDT"])
 df = await client.market_data.get_candles_last_days("binance_perpetual", "BTC-USDT", days=30, interval="4h")
 ```
 
+In a **dry run** `run_code` is refused. Read the same series with the tool instead —
+`get_market_data(action="candles", connector_name="binance_perpetual",
+trading_pair="BTC-USDT", interval="4h", max_records=180)`.
+
 The candles matter more here than for most tools: they tell you how far this pair
 actually falls in a normal pullback, which is exactly the spacing question.
 

agents/_shared/skills/directional_position/SKILL.md

@@ -52,7 +52,9 @@ Work the other way round:
    the broken level, whatever the trade is actually predicting. Use candles if you need
    the pair's typical swing:
    `run_code`: `await client.market_data.get_candles_last_days(connector, pair, days=7,
-   interval="1h")`.
+   interval="1h")`. In a dry run `run_code` is refused — use
+   `get_market_data(action="candles", connector_name=connector, trading_pair=pair,
+   interval="1h", max_records=168)`, which returns the same rows.
 2. **That distance is the stop**, expressed as a fraction of entry.
 3. **Size so that distance costs an acceptable amount.** The stop sets the risk per unit;
    the amount sets how many units. Adjust the amount, never the stop.

agents/_shared/skills/market_data_with_code/SKILL.md

@@ -3,10 +3,12 @@ name: market_data_with_code
 description: Fetch and analyse market data — use run_code for anything beyond a single
   raw value; canned snippets for common queries.
 when_to_use: 'User asks for market data: price, candles, funding rate, order book,
-  RSI/EMA/VWAP, comparisons across assets or venues, any derived calculation. The
-  only raw market data tool left is get_prices, and it is only appropriate for a single,
-  direct lookup with no computation. For everything else — indicators, multi-asset,
-  multi-venue, aggregations — write a Python snippet and call run_code.'
+  RSI/EMA/VWAP, comparisons across assets or venues, any derived calculation. Two
+  raw market data tools are left — get_prices for a single direct quote, and
+  get_market_data for plain OHLCV candles — and both are only appropriate when the
+  raw value IS the answer. For everything else — indicators, multi-asset, multi-venue,
+  aggregations — write a Python snippet and call run_code. In a dry run get_market_data
+  is the only candle read there is: run_code does not execute there.'
 created: '2026-09-02T15:29:27Z'
 source: chat
 ---
@@ -44,12 +46,37 @@ If you are reading this because a market data request just came in, do this chec
 |---|---|---|
 | Single price, one venue | `get_prices` MCP tool | 100 |
 | Single price inside run_code | `client.market_data.get_prices` | 150 |
+| Plain candles, no math on them | `get_market_data` MCP tool | 200 |
 | Order book — one or many venues | `run_code` → `get_order_book` | 350–500 |
 | Funding rate — one or many venues | `run_code` → `get_funding_info` | 350–500 |
 | Indicators (RSI / EMA / ATR / VWAP) | `run_code` → `get_candles_last_days` + pandas_ta | varies |
 | All tickers for a connector | `run_code` → `get_tickers` | 300 |
 | Multi-venue anything with math | `run_code` + `asyncio.gather` | ~500 |
-| DEX candles | GeckoTerminal — DEX connectors don't serve OHLCV | varies |
+| AMM/CLMM DEX candles (Gateway: meteora, raydium, orca, uniswap…) | GeckoTerminal — Gateway connectors don't serve OHLCV | varies |
+| CLOB DEX candles (`hyperliquid_perpetual`, …) | `get_candles*` like any CEX — CLOB DEXs are Hummingbot connectors, not Gateway; check the candle list (`xrpl` has no feed) | varies |
+
+---
+
+### In a dry run, `run_code` does not run
+
+A snippet and a routine both hold the unrestricted API client, so a dry-run
+session auto-approves neither — the refusal says so and the tick goes on. That
+leaves exactly three market reads in a rehearsal: `get_prices`,
+`explore_geckoterminal`, and
+
+```
+get_market_data(action="candles", connector_name="binance_perpetual",
+                trading_pair="SOL-USDT", interval="1h", max_records=168)
+```
+
+which returns `candles` as rows of `{timestamp, open, high, low, close, volume}`
+floats — the same numbers `client.market_data.get_candles` gives you, without the
+snippet. `action="historical_candles"` takes a unix `start_time`/`end_time` range;
+`action="connectors"` lists which venues serve OHLCV at all.
+
+Do the arithmetic in your head from the rows and say what you *would* have
+computed. Do not try to route around the refusal by writing the snippet into a
+routine — that door is closed too.
 
 ---
 
@@ -138,7 +165,8 @@ vol   = await client.market_data.get_quote_volume_for_price("binance_perpetual",
 
 **Utilities**
 ```python
-# Check which connectors serve OHLCV before using candles on a DEX connector
+# Check which connectors serve OHLCV before relying on one — Gateway AMM/CLMM
+# connectors never do; CLOB DEXs vary (hyperliquid_perpetual yes, xrpl no)
 candle_connectors = await client.market_data.get_available_candle_connectors()
 # → ["binance_perpetual", "binance", "okx_perpetual", ...]
 ```

agents/_shared/skills/open_lp_position/SKILL.md

@@ -73,6 +73,10 @@ Anchor it on realised movement rather than a guess:
 df = await client.market_data.get_candles_last_days("binance", "SOL-USDT", days=7, interval="1h")
 ```
 
+In a **dry run** `run_code` is refused. Read the same series with the tool instead —
+`get_market_data(action="candles", connector_name="binance", trading_pair="SOL-USDT",
+interval="1h", max_records=168)`.
+
 Take the recent high/low. Then:
 
 - **Actively managed (hours to a day):** roughly ±0.5–1× the pair's daily range around