[joaomdmoura]

After #7990, CrewAI reads the Enterprise Action Auth Token only from CREWAI_ENTERPRISE_ACTION_AUTH_TOKEN. Projects that still set CREWAI_PLATFORM_INTEGRATION_TOKEN got "No Enterprise Action Auth Token found", which reads as if no token was configured. An agent with apps then warned only that they "resolved to no tools", because the real error was logged at verbose level. Now the error says the old variable is set and needs renaming, and the agent's warning ends with Cause: <the error>.

• Covers the integration-token lookup in crewai_tools (used for action discovery and execution) and the warning from Agent.get_platform_tools.
• No compatibility fallback: the old variable is still not read, as Rename the platform token and preselect default app actions #7990 intended. The hint has a removal note for 2.0.
• Tests: the old-variable-only case raises the rename message, both-set still uses the new token, and the warning includes the cause only when resolution raised. The new failure-path tests fail on main.
• Docs: none changed. The messages are self-explanatory.
• Out: crewai.context.get_platform_integration_token (MCP, skills, tracing grants) still returns None silently when only the old variable is set. That needs a follow-up ticket.

🤖 Generated with Claude Code

---

Note

Low Risk
User-facing error and warning text only; auth still reads CREWAI_ENTERPRISE_ACTION_AUTH_TOKEN with no legacy fallback.

Overview
Improves diagnostics after the enterprise auth env var rename (#7990): users who still set CREWAI_PLATFORM_INTEGRATION_TOKEN alone no longer see a generic “token missing” error.

get_platform_integration_token in crewai-tools now raises a ValueError that names the old variable and instructs renaming it to CREWAI_ENTERPRISE_ACTION_AUTH_TOKEN (same value; no read of the legacy name). Agent.get_platform_tools appends Cause: <exception> to the existing UserWarning when platform tool resolution fails, so rename/API errors surface without verbose logging.

Tests cover the rename message, precedence when both vars are set, and warning cause behavior (including no Cause: when resolution returns empty without an error).

^{Reviewed by Cursor Bugbot for commit 651885e. Bugbot is set up for automated code reviews on this repo. Configure here.}

[strix-security]

Strix Security Review

✅ No open security findings.

PR summary: This PR improves the error and warning text emitted when the CrewAI Enterprise Action Auth Token is missing: it names the legacy `CREWAI_PLATFORM_INTEGRATION_TOKEN` variable that projects still set, and appends the underlying resolution error to the agent's "apps resolved to no tools" warning.

Review summary

The change is limited to two diagnostics paths: the platform-token lookup in crewai_tools now explains that the legacy CREWAI_PLATFORM_INTEGRATION_TOKEN variable is no longer read, and the agent's platform-tools UserWarning now appends the resolution error as a cause. I reviewed both changed hunks plus their callers (Agent.get_platform_tools, Crew.__prepare_tools, mcp/tool_resolver._fetch_amp_mcp_configs) and the integration client code that produces the errors. The new hint message is built from fixed literal text and never includes the token value, keeps the previous fail-closed behaviour, and the both-set case still authenticates with the new variable. Moving the exception text from the verbose-gated logger into an always-emitted warning was checked as a possible disclosure or log-injection vector and does not hold up: the only exception that can embed the token is a requests header-validation error reachable solely from the operator's own malformed value in the same process, response bodies are not carried in str(e), escaping via !r prevents newline/ANSI forging, and the default warning sink is plain stderr with no capture or telemetry forwarding. No security issues found in the changed code.

Ruled out (2)

• Can an exception message leak the enterprise action token, or reflow upstream response content, into the unconditional platform-tools warning?
  The only token-bearing exception reachable is a requests header-validation error caused by the operator's own malformed value, response bodies are not included in str(e), quoting preserves newlines and ANSI escapes, and the warning sink is plain stderr with no capture or telemetry forwarding.
• Does the new rename hint expose the token value or weaken token handling?
  The message interpolates only fixed literal variable names, still fails closed exactly as before, and the both-set case continues to authenticate with CREWAI_ENTERPRISE_ACTION_AUTH_TOKEN.

_{Review 1 on this PR · 651885e · requested Oct 26 21:34 UTC when the PR was opened}

---

Reviewed by Strix
_{Re-run review · Configure security review settings}

[alex-clawd]

Approving. Small, well-scoped, and it fixes a genuinely bad failure mode.

The bug worth fixing

After #7990 the old variable stopped being read, so a project that still set CREWAI_PLATFORM_INTEGRATION_TOKEN got "No Enterprise Action Auth Token found" — which tells the user the opposite of what is true. They had configured a token; it was just under the old name. That is the kind of message that costs someone an afternoon.

The second half is the part I like more. The real error was going to self._logger.log("error", ...), which is verbose-gated, so by default the user saw only:

Agent 'X' declares apps [gmail] but none resolved to any tools

with no cause at all. Appending Cause: <error> to the warning means the actual reason travels with the symptom. Generic improvement, not specific to this rename — any future resolution failure (API 503, bad app name) now surfaces too, which the second test covers explicitly.

Checks I made

No token values leak into the new message. The Cause: suffix forwards whatever CrewaiPlatformTools raised, so I read every raise site in crewai_platform_tools/. All of them name variables or selectors; none interpolate a token value. The new ValueError names CREWAI_PLATFORM_INTEGRATION_TOKEN and CREWAI_ENTERPRISE_ACTION_AUTH_TOKEN as names, never their contents. Worth confirming given this message now reaches stderr by default where the old one did not.

No silent fallback. The new branch only fires when the new variable is empty and the old one is set, and it raises rather than reading the old value. #7990's intent holds — the error is a signpost, not a compatibility shim. The Remove in 2.0 comment is on the branch itself, which is where someone will actually see it.

Precedence is pinned by a test. test_clipper_client_ignores_the_old_token_when_the_new_one_is_set asserts the Authorization header carries new_token when both are set. Easy case to get backwards, good to have locked.

cause = "" default. test_get_platform_tools_warning_has_no_cause_without_an_error covers the case where resolution returns empty without raising, so the warning does not grow a dangling Cause:. Small detail, but it is the one that would look sloppy in the common "app name typo" path.

One thing I appreciated in the description

Out: crewai.context.get_platform_integration_token (MCP, skills, tracing grants) still returns None silently when only the old variable is set. That needs a follow-up ticket.

That is the same class of bug, still live on a different path, and it is named rather than quietly left. Worth actually filing — a user who renames the variable because of this error message will fix action discovery and still hit silent None on MCP and tracing grants, which is a confusing second trip.

Unlike #8622 and #8623, the description here matches the code exactly, including the scope limits. All 26 checks green.