Yichen Jiang
103dac1b3c
The Web search switch selects the DeepSeek Search and Fetch APIs together, and both reuse the DeepSeek chat key by default. Neither provider answered readiness, so a step without a usable key was offered web_search and web_fetch whose every call failed, and a conversation on another provider's model or behind a gateway sent the chat key to DeepSeek. dsh-web gives WebFetchProvider an optional ready(llmProvider) and adds ctx.web.fetchReady(), which asks only the provider fetch() selects, as searchReady() does for search. tool-web registers web_fetch with a step activation condition on fetchReady(), so a step that cannot fetch leaves the tool out of declarations, guidance, and PTC bindings and refuses a call to it as UNKNOWN_TOOL; without web_fetch the search guidance uses its search-only text. The shipped HTTP fetch provider has no ready() and stays admitted. web-deepseek-api applies the API-key rules of Messages search to both APIs: without a literal apiKey, an apiKeyEnv other than DEEPSEEK_API_KEY, or a baseURL other than the default, the chat key goes only to the DeepSeek routes and only to an API base on the official chat route's origin. The refusal sits in the key's only resolver, and both providers' ready() answers presence in the order an operation resolves credentials. The transport repeats these checks so the package still does not depend on dsh-web-search-deepseek.
description, kind
| description | kind |
|---|---|
| Runtime API inspection, process-local runners, and historical Cordis cards. | package-group |
packages/extensions
English | 中文
Summary
The extensions group provides read-only runtime API discovery for agents, process-local runners for programmatic and browser consumers, and historical generated-plugin cards. Standard and Creator modes install persistent plugins through Plugin Manager. Choose a child package for inspection, Host execution, Client execution, or browser controls.
Table of Contents
Packages
| Package | Role | ctx key |
|---|---|---|
tool-cordis |
Two read-only tools for runtime API discovery | registers on ctx.tools |
cordis-host-runner |
Host half: definition registry, sandboxed host-half lifecycle, and the inspect registry that answers browser queries | provides ctx.dynamicCordisRunner and ctx.cordisInspect |
cordis-client-runner |
Browser half: evaluates a browser-half source into a live plugin and answers run requests | client face; provides browser ctx.dynamicCordisRunner |
ui-cordis |
Browser panel and historical lifecycle tool cards | client face; registers slots |
Related documentation
- Extensions subsystem — the generated
ctx.cordisInspectandctx.dynamicCordisRunnerservice API. - Generated tool catalog — the two read-only tool schemas.
- Generated configuration catalog — the runner's accepted config fields.
- Self-referential Cordis toolset reference — design home for sandbox semantics, lifecycle, and composition.
- Client shells and dynamic packages Agent Note — package placement and build faces for the client halves.
Dev Note
Working context for maintainers — click to expand
The two browser-half packages live in this group rather than under packages/client/ because they are halves of this subsystem's dual-half packages; the client face compiles them through the client program, while the host program references only the host runner.