Conversation
5bc3961 to
3f18602
Compare
codex-rs/core/src/codex.rs
Outdated
| err.message | ||
| ); | ||
| } | ||
| for plugin in loaded_plugins |
There was a problem hiding this comment.
can this be logged in plugins_manager.plugins_for_config ?
|
|
||
| impl Error for SkillParseError {} | ||
|
|
||
| pub fn load_skills(config: &Config) -> SkillLoadOutcome { |
There was a problem hiding this comment.
Cleanup of functions not longer in use.
d1b1ca9 to
f456da7
Compare
eca26e2 to
0842dc7
Compare
0842dc7 to
b68896a
Compare
sayan-oai
left a comment
There was a problem hiding this comment.
one main question about different config sources for loading plugins
codex-rs/core/src/plugins.rs
Outdated
| return PluginLoadOutcome::default(); | ||
| } | ||
|
|
||
| if !force_reload && let Some(outcome) = self.cached_outcome() { |
There was a problem hiding this comment.
plugins() is reading the global config stack reloaded from disk, but plugins_for_config() above reads from the session's resolved config_layer_stack.
yet both write to/read from the same cache slot.
so skills_for_cwd() can reuse plugin roots from a different config stack
There was a problem hiding this comment.
configured_plugins_from_stack currently reads only from the user layer, so the behavior is consistent for now. We should decide whether we actually need per-cwd plugin loading at all.
There was a problem hiding this comment.
Added a comment to the function.
There was a problem hiding this comment.
hmm, i dont see a need for per-cwd plugin loading right now
There was a problem hiding this comment.
Actually maybe it would be useful. Let me add it back.
sayan-oai
left a comment
There was a problem hiding this comment.
moving back to per-cwd cache, other than that lgtm
ec1be01 to
8da5d5c
Compare
Support loading plugins.
Plugins can now be enabled via [plugins.] in config.toml. They are loaded as first-class entities through PluginsManager, and their default skills/ and .mcp.json contributions are integrated into the existing skills and MCP flows.