respect workspace option for disabling plugins#18907
Conversation
|
All contributors have signed the CLA ✍️ ✅ |
There was a problem hiding this comment.
💡 Codex Review
plugin/install does not check workspace_codex_plugins_enabled, so a client can still install plugins when workspace settings disable plugins (by calling with a known marketplacePath/pluginName). This bypasses the new policy enforcement added to plugin/list, skills/list, and app listing, and can still activate plugin MCP/app behavior.
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
…disabling-plugins # Conflicts: # codex-rs/app-server/src/codex_message_processor.rs
|
I have read the CLA Document and I hereby sign the CLA |
|
|
||
| let settings: WorkspaceSettingsResponse = chatgpt_get_request_with_timeout( | ||
| config, | ||
| format!("/accounts/{account_id}/settings"), |
There was a problem hiding this comment.
Do we have to sanitize or sanity check account_id or does token_data take care of that for us?
Guess you mean @xl-openai? |
|
So add a remote API call for most plugin API calls? My major concern is performance. Should we cache the result? |
|
added a 24 hour workspace settings cache |
| use crate::chatgpt_client::chatgpt_get_request_with_timeout; | ||
|
|
||
| const WORKSPACE_SETTINGS_TIMEOUT: Duration = Duration::from_secs(10); | ||
| const WORKSPACE_SETTINGS_CACHE_TTL: Duration = Duration::from_secs(24 * 60 * 60); |
There was a problem hiding this comment.
I think 15 mins is good enough.
Respects the workspace setting for plugins in Codex
Plugins menu disappears
Plugins do not load
Plugins do not load in composer
no plugins loaded
no plugins in menu
