config.yaml `enabled: false` is ignored for builtin extensions — `developer` (shell/text_editor) tools remain callable in `biorouter run`

[Broccolito]

Summary

Setting enabled: false for a builtin extension in ~/.config/biorouter/config.yaml does not actually remove its tools from a biorouter run session. The agent can still call them.

Environment

• biorouter 1.88.3, macOS (Apple Silicon)
• Headless: biorouter run --quiet --output-format json --provider ... --model ... -t "..."

Reproduction

1. In ~/.config/biorouter/config.yaml, set the developer (and computercontroller) builtin blocks to enabled: false:

  developer:
    enabled: false
    type: builtin
    name: developer
    ...
  computercontroller:
    enabled: false
    type: builtin
    ...

2. Run any headless biorouter run task that tempts the model toward shell/file work.
3. Observe the transcript: the model still calls shell and text_editor (the developer builtin's tools).

Confirmed over a large automated batch: with the config above in place (file unmodified since), transcripts recorded 11 shell and 12 text_editor calls, including runs executed many hours after the config change. Other builtins whose tools also still appeared: read_file, read_app/update_app, kb_search.

Expected

enabled: false should remove that extension's tools from the session (they should not be offered to the model, and calls to them should not be possible) — the same way a disabled stdio extension's tools disappear.

Actual

The tools remain available and callable. There appears to be no supported way to disable a builtin's tools for headless runs via config.

Impact

• Reproducibility/benchmarking: you cannot pin the tool environment for a controlled run. We wanted an EHR-tools-only environment; the config said the shell tools were off, but agents kept using them, so the intended environment was never in effect.
• Safety/blast radius: operators who disable developer/computercontroller reasonably expect shell and filesystem/GUI-control tools to be gone. They are not.
• It also keeps a related failure alive: shell commands writing to protected paths trigger the permission gate that hangs headless runs (see Headless runs hang ~30 min on 'sensitive system operation' permission prompts (protected-path writes), then fail with misleading Error: not connected; prompt text corrupts --output-format json #40) — disabling developer looks like a workaround but does not work.

Suggestion

Honor enabled: false for builtins in biorouter run (filter them out of the tool list at session construction), or document a supported mechanism (CLI flag / env var / permission.yaml never_allow) to run with a restricted builtin tool set, and make --with-builtin the sole opt-in when specified.

[Broccolito]

Investigated forensically against this machine's own benchmark data — the reported repro doesn't reproduce, and the timeline resolves it: enabled: false is honored for fresh biorouter run sessions. sessions.db timestamps are UTC while the config-edit timestamps are local PDT; every bench session that loaded developer was created before the config edit (07:46 UTC), and all 138 sessions created after it loaded neither developer nor computercontroller and made zero shell/text_editor calls. The "hours after the change" reading was the UTC-vs-PDT offset.

That said, the sweep hardened the loopholes that could bite this workflow for real: the agent-facing manage_extensions tool now refuses to enable an extension whose persisted config entry says enabled: false (operator-authored disables only — injected platform defaults stay enable-able), telling the model to ask the user instead, and search_available_extensions labels operator-disabled entries. So a pinned tool environment stays pinned even against an agent that tries to turn tools back on mid-run.

Commits: git log --oneline --grep "(#42)" (merged in 75e84b6).