bee-tui 1.2.0

Production-grade k9s-style terminal cockpit for Ethereum Swarm Bee node operators.
Documentation 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104

# `:diagnose`

Dump the cockpit's current snapshot + recent HTTP log to a
text file. The thing you attach to a support thread.

```
:diagnose
:diag       (alias)
```

## What it captures

Three sections, in this order:

1. **Profile** — the active node's name + URL.
2. **Health gates** — every S1 gate's status and value at
   the moment of capture. So if a reviewer asks "what was
   bin saturation showing?" you don't need to remember; it's
   in the bundle.
3. **Last 50 API calls** — most recent entries from the
   live LogCapture buffer. Method, path, status, elapsed.

The output looks like:

```
# bee-tui diagnostic bundle
# generated UTC 2026-05-07T08:14:32Z

## profile
  name      prod-1
  endpoint  http://10.0.1.5:1633

## health gates
  ✓ API reachable                last_ping 34ms
  ✓ Chain RPC                    block 234,512 / tip 234,514 (Δ +2)
  ✓ Wallet funded                BZZ 12.50 · native 0.0421 ETH
  ⚠ Bin saturation               2 starving: bin 4, bin 5
  ...

## last API calls (path only — Bearer tokens, if any, live in headers and aren't captured)
  08:14:01.123 GET   /health                          200      34ms
  08:14:01.456 GET   /chainstate                      200      18ms
  ...

## generated by bee-tui 1.0.0
```

## Where the file goes

`$TMPDIR/bee-tui-diagnostic-<unix-timestamp>.txt`. On Linux
that's typically `/tmp/`. The cockpit prints the full path
in the status line:

```
diagnostic bundle exported to /tmp/bee-tui-diagnostic-1715056472.txt
```

Each invocation gets its own timestamp; you can run
`:diagnose` multiple times in a session and not overwrite
the earlier capture.

## What's NOT captured

This is the important part — the bundle is safe to share:

- **Bearer tokens.** They live in HTTP `Authorization`
  headers; LogCapture only sees method + URL. Tokens *never*
  appear in the file.
- **Request / response bodies.** Only metadata (status code,
  elapsed time) is in the buffer.
- **Wallet private keys.** Bee doesn't expose them via the
  API and the cockpit never asks.
- **Anything from your `config.toml`** beyond the active
  profile name + URL. The TOML file itself is not read into
  the bundle.

You can paste the bundle into a public GitHub issue, a
support email, or a Discord help channel without redacting.

## When to use it

- **Bug report**: paste the bundle into the issue body.
  Reviewers see what your node actually looked like at the
  moment of the bug, not just your description.
- **Operator handoff**: when transferring node ownership,
  capture a baseline "what does normal look like" bundle.
- **Before a risky operation**: backup the current state.
  Doesn't roll back anything; just records what was true.

## What to compare against

Two bundles, 5 minutes apart, are a quick diff for "did
anything change?". Just `diff` them.

For longer-term comparison, save bundles per day; the
elapsed columns let you see whether call latency drifted.

## See also

- [The `:command` bar](./bar.md)
- [S1 — Health gates](../screens/s1-health.md) (the gates
  you'll see in the bundle)
- [S10 — Command log](../screens/s10-log.md) (the live
  version of the "Last API calls" section)