feat: LiveTail support in cx (parity with cxctl livetail)

[naamanhirschfeld-armis]

Summary

cx currently has no LiveTail equivalent. The migration note in docs/configuration.md states this explicitly:

cx replaces the older Scala-based cxctl. … cx does not currently cover all legacy surfaces, including LiveTail and account invite flows.

We'd like to request LiveTail as a first-class cx subcommand so that cxctl can be retired.

Why this matters to us

LiveTail is the only cxctl surface we still depend on. We wrap it in an internal developer CLI, roughly:

cxctl livetail --region <region> --api-key <key> --format <fmt> | jq -r '<expr>'

The blocker is architecture, not features. cxctl is published only as cxctl-Linux.gz and cxctl-macOS.gz, and the macOS build is x86_64-only:

$ file cxctl-macOS
cxctl-macOS: Mach-O 64-bit executable x86_64

We checked every version in the public bucket (v0.3.1 through v0.3.26, plus latest) and none ships an arm64 or aarch64 asset. We're migrating our developer machines and build fleet to arm64 (Apple Silicon and Graviton), so cxctl is the one tool that still requires Rosetta / emulation.

cx already solves this — you publish aarch64-apple-darwin and aarch64-unknown-linux-musl builds. LiveTail parity would let us drop the emulated dependency entirely.

What would be sufficient

A streaming subcommand that follows new logs until interrupted, with:

• region / endpoint and API-key auth consistent with the rest of cx
• a filter or query expression to scope the stream (subsystem/application, or DataPrime)
• line-oriented output suitable for piping — NDJSON or a raw format, so downstream jq still works
• non-zero exit on auth/connection failure

We don't need feature parity with cxctl's flag surface; a documented streaming primitive we can build on is enough.

Alternatives we considered

• Keep cxctl under emulation. Works today, and is our interim plan, but it means keeping Rosetta on every workstation for a single binary.
• Call the LiveTail API directly. Viable, since we already use the query API, but we'd rather depend on a supported CLI than an endpoint we'd be reverse-engineering.

Happy to test a preview build if that's useful. Thanks for cx — the arm64 and static-musl builds are appreciated.

[naamanhirschfeld-armis]

Note. we currently have to run the old CLI using rosetta emulation. Rosetta is scheduled to be sunsetted at the end of this year. So this is quite important for us @ Armis.

[naamanhirschfeld-armis]

We're willing to implement this ourselves, but reading through contributing/ we hit two design questions we don't think we should answer unilaterally. Laying out the use case and a proposal so you can point us at the right archetype.

Use case

We wrap log tailing in an internal developer CLI. One command, used many times a day, currently shells out to:

cxctl livetail --region <region> --api-key <key> --format <fmt> | jq -r '<expr>'

LiveTail is the only cxctl surface we still depend on — everything else we need is already in cx. The reason it's now urgent for us rather than cosmetic: we're moving our developer machines and build fleet to arm64 (Apple Silicon and Graviton), and cxctl ships only cxctl-Linux.gz / cxctl-macOS.gz, with the macOS build being x86_64-only:

$ file cxctl-macOS
cxctl-macOS: Mach-O 64-bit executable x86_64

We checked every version in the public bucket (v0.3.1 through v0.3.26, plus latest) — none ships an arm64 asset. cx already publishes aarch64-apple-darwin and aarch64-unknown-linux-musl, so LiveTail parity is what lets us drop the emulated dependency.

The two blockers we ran into

1. Transport. contributing/adding-a-command.md states:

Important: All API integrations must use REST (HTTP). Do not use gRPC - the CLI is HTTP-only by design.

We could not find a documented REST/HTTP LiveTail endpoint — the public docs describe LiveTail as a real-time pre-index stream without an HTTP contract. If it is gRPC-only, then a faithful implementation appears to conflict with the HTTP-only rule, which may be exactly why this surface is still missing.

2. Streaming primitive. CxClient::post_raw buffers the full response body (send() then checked_text()), which is fine for the DataPrime NDJSON endpoint but not for an unbounded tail. A real tail needs incremental reads (bytes_stream() or similar) in src/api_client.rs — which CONTRIBUTING.md lists as shared infrastructure owned by @coralogix/team-cxai. We'd rather not open a PR that changes core-owned code without a nod first.

What we propose

Two paths, and we're happy with either:

Option A — real LiveTail, if there's an HTTP surface. If a REST/streaming LiveTail endpoint exists (or is planned), point us at the contract — path, auth, request shape, response framing — and confirm you'd accept an incremental-streaming helper in api_client.rs. We'll implement it as a REST archetype command with the required skills/ entry, unit tests, and an #[ignore]d e2e test in tests/e2e/.

Option B — cx logs --follow, as an interim. If LiveTail stays gRPC-only, we'd propose a --follow flag on the existing cx logs that polls /api/v1/dataprime/query on an advancing time cursor, emitting only new rows. Concretely:

• reuses dataprime::run_query, so no change to api_client.rs
• --interval for poll cadence, cursor advanced from the last seen $m.timestamp, with de-duplication on the boundary
• documented honestly as post-index polling, not zero-latency pre-index LiveTail — different semantics, and we would not name it livetail
• unit tests for cursor advance, boundary de-dup, and backoff; plus an #[ignore]d e2e test

Option B covers our use case and most tail -f-shaped workflows, without touching core infrastructure or the HTTP-only rule. It is explicitly not a substitute for LiveTail's latency characteristics.

Per the lifecycle in CONTRIBUTING.md we're treating this as the proposal step and waiting on design review before implementing. Which archetype would you like us to take? We have a fork ready and can turn either around quickly.