buzz-acp: most log targets are invisible under the RUST_LOG the desktop injects
- Dominant language
- Rust
- Stars
- 32.7k
- Forks
- 4.3k
- Avg merge
- 1d 13h
- Merged PRs (30d)
- 253
Description
## Summary
`buzz-acp` logs 102 call sites under bare targets (`pool::prompt`, `acp::wire`, `canvas::fetch`, …). `EnvFilter` matches targets by `::`-separated prefix, so none of them match a `buzz_acp` filter — and `buzz_acp` is the only filter a managed agent ever runs with.
The result is that a managed agent's log records which channels it subscribed to, but not what it then did with them.
## Why every managed agent hits this
Two independent places pin the filter to `buzz_acp`:
- the harness default: `EnvFilter::try_from_default_env().unwrap_or_else(|_| EnvFilter::new("buzz_acp=info"))` in `lib.rs`
- Buzz Desktop injects `RUST_LOG=buzz_acp=info` into every managed agent, which takes precedence over that default
Verified on a running agent:
```
$ ps eww -o command= -p | tr ' ' '\n' | grep RUST_LOG
RUST_LOG=buzz_acp=info
```
So changing only the harness default does not fix it — the environment wins. I tried that first.
## Scope
19 distinct targets, 102 call sites, all invisible in a managed agent:
| target | call sites |
|---|---:|
| `pool::prompt` | 17 |
| `canvas::fetch` | 11 |
| `acp::wire` | 11 |
| `pool::model` | 5 |
| `pool::effort` | 5 |
| `pool::permission` | 4 |
| `pool::metrics` | 4 |
| `engram::core` | 4 |
| `acp::usage` | 4 |
| `acp::update` | 4 |
| `acp::permission` | 3 |
| `acp::tool`, `acp::cancel`, `observer` | 2 each |
| `acp::thought`, `acp::stream`, `acp::session`, `acp::plan`, `acp::init` | 1 each |
By file: `pool.rs` 48, `acp.rs` 31, `lib.rs` 1, `engram_fetch.rs` 1.
## What this costs in practice
These are the lines an operator needs when something goes wrong, and none of them are emitted:
- `pool::model` / `pool::effort` — why a model switch or an effort level did not apply
- `canvas::fetch` — why a channel canvas is missing from the prompt
- `engram::core` — why core memory was not injected
- `acp::wire` — the adapter conversation itself
- `pool::prompt` — what was actually dispatched
Nothing is broken at runtime; the information simply never reaches the log. It reads as "the agent did nothing", which is indistinguishable from an actual stall.
## Repro
1. Run any managed agent from Buzz Desktop
2. Mention it so it takes a turn
3. `grep 'pool::' ~/Library/Application\ Support/xyz.block.buzz.app/agents/logs/*.log`
Zero matches, though the turn ran.
## Suggested fix
Prefix the targets with the crate path — `buzz_acp::pool::prompt`, `buzz_acp::acp::wire`, and so on. That keeps the finer granularity for anyone who sets `RUST_LOG` deliberately (`RUST_LOG=buzz_acp::acp::wire=debug` still works), while making the lines visible under the filter the desktop already imposes, with no configuration change on either side.
Widening the desktop's injected `RUST_LOG` would also work, but it silently depends on the desktop and the harness agreeing on a list of target names.
Happy to send a PR if the prefix approach looks right to you.
## Environment
macOS 15, Buzz Desktop built from `main`, `buzz-acp` from the same tree.
Contributor guide
Assessment
This issue has not been assessed yet.