redteamsfr/tests-tui repository overview

⁠tests-tui — sandbox for analyzing and debugging LLM agent harnesses

A ready-to-use Linux environment to run, instrument, and analyze LLM agents from the CLI.

Outbound traffic from every embedded tool is automatically routed through LLMiddler, so you can observe, replay, or modify the requests without changing a line of your harness code.

⁠Quick start

Create a .env file:

MISTRAL_API_KEY=...

Start the container:

docker run --init \
  -p 8090:8090 -p 9090:9090 \
  --env-file .env \
  -e TZ=Europe/Paris \
  -it --rm \
  redteamsfr/tests-tui:latest-light bash

Then open the Web UI: http://localhost:8090/_ui/⁠

⁠Working on your own code

The /workspace/mount directory is meant to be bind-mounted from the host:

docker run --init \
  -p 8090:8090 -p 9090:9090 \
  --env-file .env \
  -v "$PWD:/workspace/mount" \
  -it --rm \
  redteamsfr/tests-tui:latest-light bash

Your current host directory shows up under /workspace/mount inside the container, editable from either the in-container shell or your local IDE.

⁠What's inside

Agents and CLIs

• vibe (Mistral AI)
• opencode

LLM observability

• llmiddler-gateway — ingest service and analysis UI

Tools

• Day-to-day shell: git, vim, nano, tmux, htop, ripgrep, tree, jq, less, python3, node/npm

⁠How it works

1. Configure your harness to use a standard LLM endpoint (Mistral, OpenAI, Anthropic, etc.).
2. The embedded transparent proxy intercepts the outbound request, forwards it to the provider, and ships a copy to the gateway for analysis.
3. The Web UI shows you conversations, token usage, and tool calls.

No harness changes needed: as long as it honors the HTTP_PROXY / HTTPS_PROXY environment variables (which most SDKs do), it just works.

⁠Image variants

The light variant covers text-only workflows. The full image adds browsers for agents that can navigate the web.

⁠Tags and versioning policy

Two flavors of tags are published, with different stability guarantees.

Pinned tags — :vX.Y.Z-light, :vX.Y.Z

Each git tag of the form vX.Y.Z triggers a build that pushes the matching Docker tag. Treat these as immutable: once published, a given vX.Y.Z[-light] tag is meant to keep referencing the same image. We do not re-publish over an existing version tag.

If you want a reproducible deployment, pin to vX.Y.Z[-light] (or to the image digest, @sha256:..., for a stronger guarantee that survives even accidental overwrites).

Floating tags — :latest-light, :latest

These are updated on every release and always point to the most recent vX.Y.Z[-light] build. Convenient for trying things out, but not recommended for any environment where you care about reproducibility.

The image follows semantic versioning⁠: a bump in MAJOR may include breaking changes, MINOR adds features in a backwards-compatible way, PATCH is bug fixes only.

Enjoy !