WIP: fix refresh extension not working

[NKoech123]

Summary

Adds two new agent actions, extension-data-set and extension-data-get, that let the agent directly read and write an extension's tool_data store without going through the iframe bridge or raw SQL.

Problem

Agents had no reliable way to refresh data used by an extension (e.g. a dashboard) from the agent side. The only path was routing through the sandboxed iframe bridge or raw SQL, which is not accessible/safe for agent-driven updates, making it impossible for the agent to seed or refresh data that an extension reads via extensionData.get() at render time.

Solution

Introduce two dedicated actions that wrap access-controlled reads/writes to the tool_data table, allowing an agent to fetch fresh data from providers and persist it directly for an extension to pick up on next load.

Key Changes

• Added extension-data-set action: upserts an item into an extension's data store (tool_data), enforcing editor access, a 1MB payload size limit, and scope (user or org) handling with Postgres/SQLite-compatible upsert conflict clauses.
• Added extension-data-get action: reads a single item or lists items from an extension's data store, enforcing viewer access, with support for user, org, or all scope filtering and a configurable result limit.
• Both actions call ensureExtensionsTables() before executing and use resolveAccess to enforce permission checks tied to the extension.
• Updated SKILL.md documentation to describe the new agent-side extension data access pattern, including guidance that this is the correct path for agent-driven dashboard refreshes.

---

  

---

To clone this PR locally use the Github CLI with command gh pr checkout 2170

You can tag me at @BuilderIO for anything you want me to fix or change

[github-actions]

Here's a visual recap of what changed:

Open the full interactive recap

[builder-io-integration]

Builder reviewed your changes and found 2 potential issues 🔴

Review Details

Code Review Summary

PR #2170 adds two agent-facing actions for extension tool_data: an access-controlled upsert and a scoped read/list operation, plus guidance in the extensions skill. The implementation uses parameterized SQL, ensures the extension tables exist, enforces editor/viewer access, caps individual writes at 1 MiB, and supports both PostgreSQL and SQLite conflict syntax. The overall architecture is appropriate and avoids exposing raw SQL or iframe bridge details to the agent.

Risk level: High, because this change introduces security-sensitive scoped reads and persistent data mutation.

Key Findings

• 🔴 HIGH — extension-data-get does not reject scope="org" when no organization context exists; it queries using an empty organization id instead of failing closed.
• 🟡 MEDIUM — List responses are limited by row count but not aggregate size, so 1,000 individually valid 1 MiB values can create an excessively large agent result and exhaust serialization/context resources.

🧪 Browser testing: Skipped — PR only modifies backend action wiring and agent documentation, with no user-facing UI changes.

[builder-io-integration]

🔴 Reject organization reads without organization context

When scope="org", this path passes orgId ?? "" to SQL without first requiring an organization context. Fail closed as extension-data-set does; otherwise org-scoped reads from a non-org context can silently query an invalid scope and may expose rows if empty/null organization identifiers exist.

Additional Info

Found by one code-review agent; matches the existing validation pattern in extension-data-set and extension routes.

[builder-io-integration]

🟡 Bound list responses by aggregate size

The list operation caps rows at 1,000 but has no aggregate response-size limit, while each stored value may be up to 1 MiB. A populated collection can therefore produce a very large agent tool result, exhausting serialization or model context resources; add a byte/character cap or return a bounded, explicitly truncated result.

Additional Info

Found by one code-review agent; based on the 1 MiB per-item write limit and 1,000-item read limit.