fix(tools): render_widget follows the assistant's data access; no widget is rendered until a host allows it #112

2026-11-15T11:31:13Z

james.maes commented

2026-11-15 11:31:13 +00:00

What

render_widget now follows the assistant's own data-access rules. Until this change it asked the application to render any widget the signed-in person may see. A widget is code of the application and can show rows of any table, so it could hand a model the rows of a table the assistant may not read (data access NONE, a table kept from AI by its metadata).

The rule

A widget is rendered only when all of these hold, checked in UiApiToolbox.renderWidget before the application is asked:

the host named it in AssistantQBitConfig.withAllowedWidgetNames (empty by default: no widget is renderable until a host allows one);
it is not in withHiddenWidgetNames;
the assistant may read every table the host said the widget reads: new AssistantQBitConfig.withWidgetTables(widgetName, tableNames). A NONE row of an administrator, a pin in code and a table kept from AI each close the widget too.

Everything else is refused with one answer ("The widget ... is not available to the assistant."), which does not say whether the widget exists. The refusal is a DENIED result with a tool-call row (widget:notAllowed, widget:hidden, dataAccess:table:<mode>).

The README already said the allow-list governs the tool. Since the tool moved from the core tool kernel to the UI API, the list only reached the kernel's settings and the tool did not read it.

What a host must change

Only if it wants the assistant to render widgets: name them, and name the tables each one reads (see UPGRADE.md). No schema change, no permission, no settings row.

Not in this change

The tool is still offered as before, so its definition and the cached request prefix do not change. Not offering it at all while no widget is allowed changes the tool set of every request and the hand-kept tool-set file; it is left for a follow-up.

Tests

RenderWidgetAccessTest: the default is closed and the application is not asked to render; an allowed widget renders; a hidden one is refused also when allowed; a widget whose declared table is closed by a pin is refused and its rows do not reach the model; read-only is enough to read; a declared table that does not exist closes the widget.

Full gated build of this branch's head (./mvnw verify: Checkstyle, SpotBugs, PMD, tests, coverage; no gate skipped): BUILD SUCCESS, 725 tests (602 in qbit-assistant), 0 failures, every coverage check met.

🤖 Generated with Claude Code

## What `render_widget` now follows the assistant's own data-access rules. Until this change it asked the application to render any widget the signed-in person may see. A widget is code of the application and can show rows of any table, so it could hand a model the rows of a table the assistant may not read (data access `NONE`, a table kept from AI by its metadata). ## The rule A widget is rendered only when all of these hold, checked in `UiApiToolbox.renderWidget` before the application is asked: 1. the host named it in `AssistantQBitConfig.withAllowedWidgetNames` (empty by default: **no widget is renderable until a host allows one**); 2. it is not in `withHiddenWidgetNames`; 3. the assistant may read every table the host said the widget reads: new `AssistantQBitConfig.withWidgetTables(widgetName, tableNames)`. A `NONE` row of an administrator, a pin in code and a table kept from AI each close the widget too. Everything else is refused with one answer ("The widget ... is not available to the assistant."), which does not say whether the widget exists. The refusal is a DENIED result with a tool-call row (`widget:notAllowed`, `widget:hidden`, `dataAccess:table:<mode>`). The README already said the allow-list governs the tool. Since the tool moved from the core tool kernel to the UI API, the list only reached the kernel's settings and the tool did not read it. ## What a host must change Only if it wants the assistant to render widgets: name them, and name the tables each one reads (see `UPGRADE.md`). No schema change, no permission, no settings row. ## Not in this change The tool is still offered as before, so its definition and the cached request prefix do not change. Not offering it at all while no widget is allowed changes the tool set of every request and the hand-kept tool-set file; it is left for a follow-up. ## Tests `RenderWidgetAccessTest`: the default is closed and the application is not asked to render; an allowed widget renders; a hidden one is refused also when allowed; a widget whose declared table is closed by a pin is refused and its rows do not reach the model; read-only is enough to read; a declared table that does not exist closes the widget. Full gated build of this branch's head (`./mvnw verify`: Checkstyle, SpotBugs, PMD, tests, coverage; no gate skipped): BUILD SUCCESS, 725 tests (602 in `qbit-assistant`), 0 failures, every coverage check met. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

james.maes added 1 commit 2026-11-15 11:31:14 +00:00

fix(tools): render_widget follows the assistant's data access; no widget is rendered until a host allows it

maven / build (push) Successful in 8m50s

Details

build / maven (push) Successful in 8m56s

Details

50845aa99b

A widget is code of the application and can show rows of any table, so
render_widget could hand a model the rows of a table the assistant may not
read. The tool now refuses, before the application is asked, every widget
the host did not allow by name (withAllowedWidgetNames, empty by default),
one it hid, and one that reads a table the assistant may not read
(new: withWidgetTables).

Co-Authored-By: Claude Fable 5.2 <noreply@anthropic.com>

james.maes referenced this pull request

2026-11-15 11:51:41 +00:00

feat(process): one confirmation runs a set to its end, within what its card showed; no card for a change the person may not make #113

james.maes referenced this pull request

2026-11-15 11:52:09 +00:00

feat(engine): compact answers; a reply cut off at the output ceiling drops no work and never ends COMPLETE #114

All checks were successful

maven / build (push) Successful in 8m50s

Details

build / maven (push) Successful in 8m56s

Details

You are not authorized to merge this pull request.