Skip to content

runtime

The web-search runtime: a lazily-resolved, process-wide config shared by the plugin and the web_search / web_fetch tools, so both read one resolved allow-list / cap / timeout set. The first caller (normally the plugin at setup) primes it from the plugin’s config; later callers (the tools’ execute) reuse it.

The runtime also carries the WebSearchExecutor every outbound call runs through. The plugin installs its own execute() there at setup, which is how the tools - plain functions with no plugin instance in scope - still get AppKit’s cache / retry / timeout / telemetry chain. Without a registered plugin (a direct call from a script or a test) the calls still run, just without interceptors.

Unlike the email runtime there is no connection to pool - the backend is stateless HTTP per call - so the runtime holds only the resolved config and that executor.