Repository: confident-ai/deepeval
Issue: Backward compatibility of DEEPTEAM_TELEMETRY_OPT_OUT
Root cause: Configuration Error

The recent modification to environment variable parsing — where only numeric truthy values like 1 are accepted — introduces a security and compliance risk rather than just a configuration issue.

Previously, many teams used DEEPEVAL_TELEMETRY_ENABLED=YES (a conventional and widely accepted pattern) to explicitly disable telemetry or control outbound data flows in accordance with company policies. After the change, this flag is no longer recognized as truthy, which can silently alter the intended telemetry behavior.

In organizations with strict data governance, network egress controls, or regulatory compliance constraints, such a subtle behavioral change can result in unauthorized outbound communication — a serious issue in environments where telemetry transmission to third-party servers is disallowed.

Moreover, the related deepteam library still uses the YES variant in its configuration, creating inconsistency across dependent components. This inconsistency can easily lead to misconfigurations that are hard to diagnose and error-prone, especially when both libraries are used together in the same ecosystem.

> 🎨 It might have been a good idea to support both YES and 1 for backward compatibility. This could break in some environments , including read-only filesystems 

 _Originally posted by @fisabelle-lmi in [1ff6f8d](https://github.com/confident-ai/deepeval/commit/1ff6f8dd9b0c0903f01f55d05e8c5f3bff057805#r165437477)_

@trevor-cai could we somehow support this? something really quick would help...

Hi @agrudkow ,

Thank you for raising this and for pointing out your concerns about compliance. DeepEval continues to support flexible boolean values such as 'yes', 'no', '1', '0', and similar representations. What has caused some confusion is that the environment variable `DEEPEVAL_TELEMETRY_ENABLED` was renamed `DEEPEVAL_TELEMETRY_OPT_OUT` and with it the semantics changed.

We have reintroduced support for the legacy flag `DEEPEVAL_TELEMETRY_ENABLED` and mapped it to the current `DEEPEVAL_TELEMETRY_OPT_OUT` with the following precedence rules:

- If both are set, **any OFF signal** wins

   - `DEEPEVAL_TELEMETRY_OPT_OUT` truthy -> telemetry OFF
   - `DEEPEVAL_TELEMETRY_ENABLED` falsy -> telemetry OFF
-  Else, ON signal applies
   * `DEEPEVAL_TELEMETRY_OPT_OUT` falsy -> telemetry ON
   * `DEEPEVAL_TELEMETRY_ENABLED` truthy -> telemetry ON
-  **Unset is ON by default**

If both vars are set but conflict, we default to **OFF** and emit a warning in verbose/debug mode to make the misconfiguration visible.

Thanks again for the thoughtful feedback, this helped us provide some backwards comparability for teams still using `…TELEMETRY_ENABLED`.

> Moreover, the related deepteam library still uses the YES variant in its configuration, creating inconsistency across dependent components. This inconsistency can easily lead to misconfigurations that are hard to diagnose and error-prone, especially when both libraries are used together in the same ecosystem.

Thank you for raising this concern as well. I will bring this issue up with the team.