fix: re-apply llm tool inactivation state after plugin initialize()

[Foolllll-J]

fix: re-apply llm tool inactivation state after plugin initialize() to prevent tools registered via add_llm_tools() from being auto-enabled on reload

Background

When a plugin registers its LLM function-calling tools via context.add_llm_tools() inside its initialize() method (e.g., FunctionTool subclass pattern), and a user disables one of those tools through the management panel, the tool's name is recorded in the inactivated_llm_tools list in persistent storage. However, upon reloading that specific plugin (single-plugin reload), the framework's existing inactivation logic — which runs before initialize() — fails to catch these tools because they haven't been added to llm_tools.func_list yet. Consequently, the newly registered tools start with active=True and become re-enabled automatically, ignoring the user's previous choice.

Modifications / 改动点

A new post-initialize inactivation re-application is added immediately after the initialize() call, inside the per-plugin loading loop. It iterates llm_tools.func_list, checks whether each tool belongs to the current plugin (_is_plugin_llm_tool), and sets ft.active = False if the tool's name is in inactivated_llm_tools. This runs for every plugin regardless of reload type (single or full), closing the gap.

• Modified file: astrbot/core/star/star_manager.py (+8 lines)
• Location: After await metadata.star_cls.initialize() (line ~1418), before the OnPluginLoadedEvent trigger

if metadata.module_path:
    for ft in llm_tools.func_list:
        if self._is_plugin_llm_tool(ft, metadata.module_path):
            if ft.name in inactivated_llm_tools:
                ft.active = False

• This is NOT a breaking change. / 这不是一个破坏性变更。

Screenshots or Test Results / 运行截图或测试结果

---

Checklist / 检查清单

• 😊 If there are new features added in the PR, I have discussed it with the authors through issues/emails, etc.
  / 如果 PR 中有新加入的功能，已经通过 Issue / 邮件等方式和作者讨论过。

• 👀 My changes have been well-tested, and "Verification Steps" and "Screenshots" have been provided above.
  / 我的更改经过了良好的测试，并已在上方提供了“验证步骤”和“运行截图”。

• 🤓 I have ensured that no new dependencies are introduced, OR if new dependencies are introduced, they have been added to the appropriate locations in requirements.txt and pyproject.toml.
  / 我确保没有引入新依赖库，或者引入了新依赖库的同时将其添加到 requirements.txt 和 pyproject.toml 文件相应位置。

• 😮 My changes do not introduce malicious code.
  / 我的更改没有引入恶意代码。

Summary by Sourcery

Bug Fixes:

• Prevent LLM tools registered during plugin initialize() from being re-enabled on plugin reload when users have previously inactivated them.

[dosubot]

📄 Knowledge review

Dosu skipped reviewing this PR because your organization has used its 200 included credits for the month. Your usage will reset on 2026-08-01. To have Dosu review this PR before then, ask your organization admin to upgrade to a pro account.

---

[sourcery-ai]

Hey - I've left some high level feedback:

• The inactivation check uses only ft.name for matching, which could incorrectly disable tools across different plugins if they share names; consider scoping the persistence key or check to include plugin identity (e.g., module path) rather than just the tool name.
• You now re-apply inactivation both before and after initialize(), but with slightly different logic; extracting this into a shared helper that takes the current plugin metadata would reduce duplication and make the behavior easier to reason about.
• Iterating over llm_tools.func_list for every plugin load may become inefficient as the number of tools grows; consider tracking tools per plugin (e.g., via a registry keyed by module_path) so you only iterate the subset relevant to the current plugin.

Prompt for AI Agents

Please address the comments from this code review:

## Overall Comments
- The inactivation check uses only `ft.name` for matching, which could incorrectly disable tools across different plugins if they share names; consider scoping the persistence key or check to include plugin identity (e.g., module path) rather than just the tool name.
- You now re-apply inactivation both before and after `initialize()`, but with slightly different logic; extracting this into a shared helper that takes the current plugin metadata would reduce duplication and make the behavior easier to reason about.
- Iterating over `llm_tools.func_list` for every plugin load may become inefficient as the number of tools grows; consider tracking tools per plugin (e.g., via a registry keyed by `module_path`) so you only iterate the subset relevant to the current plugin.

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.}