Document per-session plugin directories - #2581
Open
1fanwang wants to merge 2 commits into
Open
Conversation
Closing a docs-validate hidden block sets a pending skip so the visible copy is not validated twice. A fence whose language has no validator, such as rust, was never recognized as a code block, so it never consumed that skip and the next validated block absorbed it instead. Signed-off-by: 1fanwang <1fannnw@gmail.com>
The plugin directories guide covered only the --plugin-dir launch argument and the trusted host-bundled startup option, so the per-session pluginDirectories config had no entry despite being typed in every language binding and forwarded on create and resume. Signed-off-by: 1fanwang <1fannnw@gmail.com>
Contributor
There was a problem hiding this comment.
🟢 Approval recommended
The documentation update is consistent with existing SDK option naming, and the extractor change is minimal and correctly scoped to preventing skip-directive leakage.
Pull request overview
This PR updates the plugin directories documentation to cover the per-session pluginDirectories session option (useful when different sessions need different plugins or when connecting to an external runtime), and adjusts the docs validation extractor so “hidden”/skip directives can’t leak past fenced code blocks whose language isn’t validated.
Changes:
- Documented per-session plugin directories, including a TypeScript example and the option spelling across SDKs.
- Updated
scripts/docs-validation/extract.tsto track and close unvalidated fenced blocks so pending skips are consumed correctly.
File summaries
| File | Description |
|---|---|
| scripts/docs-validation/extract.ts | Treats fences in unvalidated languages as blocks that still consume pending skip directives. |
| docs/features/plugin-directories.md | Adds a “Per-session plugin directories” section documenting pluginDirectories and cross-SDK option names. |
Review details
- Files reviewed: 2/2 changed files
- Comments generated: 0
- Review effort level: Lite
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Stacked on #2580, which the added example needs in order to be type-checked. Once that merges this reduces to the documentation commit.
Why
An SDK application wants one session to load a code-review plugin and another to load nothing, or it connects to a runtime it did not spawn. The reader opens the plugin directories guide and finds two ways to load a plugin: the
--plugin-dirlaunch argument, and the trusted host-bundled startup option for plugins the host itself ships. Neither fits. The guide says plainly that loading a plugin directory "makes its extensions visible to every session created by the client", and that the SDK does not forward--plugin-dirto runtimes it did not spawn.So the reader concludes per-session plugin sets are not supported, and reaches for a second client or a wrapper process.
They are supported. The session config takes
pluginDirectories, it is typed in all six language bindings, and the SDK forwards it on both create and resume. Because it travels in the JSON-RPC payload rather than as a process argument, it also reaches an external runtime. It simply had no entry in its own guide.After this change the reader finds it beside the two mechanisms they were already comparing.
What changed
A section covering the per-session option: what it does, how paths resolve, how it interacts with config discovery and precedence, an example, and the spelling in each language.
Testing Done
Documentation only, no code paths touched.
The option was absent from the guide before this change and present after:
The added example is compiled against the SDK types by the docs validation, so a wrong option name or type fails the build.
Raw logs: docs validation