v2.6.1

BambooAI 2.6.1 — the reach record

The kernel now records what each cell of an analysis touched outside the data, and the app reports it when the chain ends. The analysis itself is unchanged; the executor image is rebuilt (v65).

What is recorded

For every cell the analyst runs, the kernel keeps a record of the doors it went through:

• Network. Each host the cell connected to, with the port, the bytes sent and received (TLS included), a listening port it opened, a name it resolved without connecting, a connection that failed.
• Files. A file opened or a folder listed outside the data — the dataset, your own datasets folder, the generated folder, the plots folder, temp and Python's own trees are the data; /etc, home folders, dotfiles and the box's own places are not.
• Environment. A variable the cell read, or the whole environment walked.
• Programs. A program the cell started.

Each record carries the cell line it came from and is marked asked for when the question — or an earlier question of the thread — named the host, the file or the variable. "Download it from https://example.org/x.csv" names the host; "fetch it from the internet" does not, and the card says so. The rule is a plain substring test, deliberately: nothing is inferred.

The record observes; it does not block. The one address the kernel now refuses is the cloud instance metadata service (169.254.169.254), which answers with the box's own credentials. The restricted-module list is unchanged in substance, with two faults fixed: the os.exec and os.spawn entries had matched nothing, and the text of an f-string counted as code, so f"http://{host}/x" was refused as the http module.

Where it shows

• The closing card. Under the replay line: how many reaches outside the data, how many not asked for, how many cells not run; one line per reach with its cell and tag; the cells the executor refused; and the box in one line (user, root or not, capabilities worth a word, seccomp, the mounts, whether the metadata address answers). A chain that reached nothing says so in one faint line.
• The cell rows. A cell that reached out carries a short tag after its output line — ↓ 1.3 MB from host, ↑ 42 KB to host:port, read /etc/passwd, env HOME — plain when the question asked for it, in the kernel's colour when not.
• Refused cells. A cell the executor refused (the restricted-module list) is shown as its own state — ⊘ In [–] not run: restricted operation (socket) — not as a failure, in the pane, the Investigation tab and the counts.
• The code map. The same tag on the step's row, a refused attempt as its own row, and a Reaches outside the data section in the summary panel, each line opening its step.
• The tally. python3 tools/reaches_report.py --root <working folder> --days 14 reads the stored threads and the run logs and prints the record per model: runs, cells, fetched and sent (asked for or not), files, environment names, programs, refused cells, the hosts not asked for, and the lines not asked for with their question.

Nothing of the record enters a prompt: the analyst never sees it.

Not seen

A connection made by a C library (libpq, pycurl); a library's own choice of path outside the box's sensitive places; the replay and routines, which re-run the committed cells on the script route — they were observed when the chain ran. docs/REACH_DESIGN.md has the design and the decisions.

Upgrading

pip install -U bambooai
bambooai serve

serve rebuilds the executor image on first use (the tag moves to …-v65; a few minutes). Threads, favourites, memory and routines are unchanged. Chains run before the upgrade carry no record: their cards show nothing for it, and their maps say the record was not kept.

Full changelog: v2.5.1...v2.6.0