[joaomdmoura]

crewai_core.user_data.is_tracing_enabled ignored CREWAI_TRACING_ENABLED=false once consent was recorded, so crewai traces status said ENABLED while runs went untraced. It now returns False for false/0, as the runtime should_enable_tracing does. traces status shows an unset variable as not set instead of false, and crewai eval's tracing_already_on reads the project .env first, so a .env true still beats a shell false.

• Scope: is_tracing_enabled and its callers, traces status and eval_crew.tracing_already_on (also behind the run app's Evaluate button).
• Compat: the re-exports in crewai.events.listeners.tracing.utils and crewai_cli.user_data change only for false/0 with consent; other env/consent combinations are pinned unchanged.
• Tests: a 6 env x 3 user-data parity matrix against should_enable_tracing (runs in CI); the traces status and tracing_already_on caller tests fail on main, but lib/cli tests only run in CI once ci/ci-cli-core-files-tests lands.
• First of two PRs for crewai doctor: feat(cli): add crewai doctor for login, tracing and integration checks #8609 (feat/cli-doctor) stacks on this one; this one merges on its own.
• Out: traces status still ignores the project .env (needs a Linear ticket); no change to should_enable_tracing; no docs change, since the docs already say false turns tracing off.

🤖 Generated with Claude Code

[strix-security]

Strix Security Review

Warning

This pull request has 31 commits after the last Strix review (70102b3). Strix has not reviewed these changes.
Automatic review on push is off for this repository. To review the latest changes, tag @strix-security in a comment, or turn on re-review on push.

✅ No open security findings.

PR summary: This PR makes the CLI's tracing-state helper `is_tracing_enabled` treat `CREWAI_TRACING_ENABLED=false`/`0` as an explicit off (matching the runtime tracing gate), shows an unset variable as "not set" in `crewai traces status`, and makes `crewai eval`'s `tracing_already_on` consult the project `.env` before the process environment.

Review summary

I reviewed all seven changed files: the is_tracing_enabled gate in crewai_core/user_data.py, the traces status rendering in crewai_cli/cli.py, the tracing_already_on/_project_tracing_value refactor in crewai_cli/experimental/eval_crew.py, and the associated tests. The core change makes the CLI's tracing helper agree with the runtime gate by honouring CREWAI_TRACING_ENABLED=false/0 ahead of recorded consent; no authorization, redaction, or credential-handling path depends on that helper, and the new .env-first branch in tracing_already_on() changes no data flow because eval_crew loads the project .env into the process environment before any tracing decision, so the same value was already visible to the previous implementation. The run-app Evaluate path behaves identically for the same reason. The saved-login protection (untrusted_amp_stop plus the AMP-origin handshake read before the .env load) and the anonymous-grant downgrade are untouched and still run ahead of the tracing decision, so a project-supplied .env still cannot route traces or a login to an AMP the machine has not configured. The traces status change only echoes a value that comes from the invoking user's own shell environment (that command does not load the project .env), so it adds no attacker-controlled input. No security issues found in the changed code. One non-security note for the author: given that _load_project_env() runs before _run_the_crew_to_evaluate(), the new early return in tracing_already_on() is redundant on that path, and test_tracing_already_on_lets_the_project_env_beat_a_shell_false asserts a state the production call order never reaches because it does not load the project .env.

Ruled out (1)

• Can a project-supplied .env containing CREWAI_TRACING_ENABLED=true make `crewai eval` skip the trace-consent prompt and upload an unconsented trace to CrewAI A…
  The project `.env` is loaded into the process environment (override=True) before `_run_the_crew_to_evaluate`, so the previous implementation already read the same true value and already skipped the prompt, and eval-started runs are traced by design via the evaluation handshake — no new data flow or…

_{Review 1 on this PR · 70102b3 · requested Oct 26 08:10 UTC when the PR was opened}

---

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

[alex-clawd]

Approving. CREWAI_TRACING_ENABLED=false was not actually turning tracing off:

if os.getenv("CREWAI_TRACING_ENABLED", "false").lower() in ("true", "1"):
    return True
if has_user_declined_tracing():
    return False

An explicit false fell straight through to the consent check, so a user who had previously consented kept tracing on despite setting the env var to disable it. Setting a variable to false and having it ignored is worse than the variable not existing — it looks like an off switch and is not one.

The fix reads the value once and handles both directions, with false/0 checked before true/1, so explicit intent always beats recorded consent.

test_tracing_gate_parity.py is the right addition: the docstring claims this mirrors should_enable_tracing, and now a test holds the two in step rather than a comment asserting it.