fix: dont default to default user id when executing custom tools

[wjayesh]

Fix: Require explicit user_id for toolkit-backed custom tools

Summary

Removes unsafe default-fallback behavior in custom tool execution and clarifies CrewAI integration patterns.

Changes

Security fix in python/composio/core/models/custom_tools.py:

• Removed silent fallback to "default" in CustomTool.__call__
• Now raises ValueError("user_id is required when invoking toolkit-backed custom tools") when user_id is missing
• Normal (prebuilt) tools unchanged

Problem solved

• Security risk: Custom tools silently used "default" user when user_id was omitted, potentially accessing wrong connected accounts

Breaking change

• Toolkit-backed custom tools now require explicit user_id
• Migration: Always pass user_id in composio.tools.get(user_id=...) calls

Files changed

• python/composio/core/models/custom_tools.py - Enforce explicit user_id, remove default fallback

---

Note

Enforces explicit user_id for toolkit-backed custom tools and raises an error if missing, removing the previous "default" fallback.

• Core:
  • Custom tools (python/composio/core/models/custom_tools.py):
    • In CustomTool.__call__: remove fallback to "default" for user_id.
    • Require user_id when toolkit is set; raise ValueError if omitted.

^{Written by Cursor Bugbot for commit 444bfb9. This will update automatically on new commits. Configure here.}

[haxzie]

Can we make it a mandatory field while calling custom tools?

[Sushmithamallesh]

Review Summary

Thank you for the update! This PR modifies the behavior in CustomTool calls to require an explicit user_id when invoking toolkit-backed custom tools, instead of defaulting to 'default' if a user_id is not provided. This change improves safety by preventing unexpected account usage.

---

Pros:

• Eliminates the risk of unintentionally using the default account for sensitive tool executions.
• Raises clear exceptions when required parameters are missing, improving robustness.

Suggestions:

• Consider adding or updating unit tests for this path to ensure that the ValueError is raised in the correct scenario and that backwards compatibility is maintained where expected.
• Add a note to the relevant documentation (or docstrings) about this breaking change, especially if there are scripts or clients that might rely on the previous default behavior.

---

I will leave inline comments for specific lines below.