chroma-core/chroma · error · ValueError

Resetting is not allowed by this configuration (to enable it

Error message

Resetting is not allowed by this configuration (to enable it, set `allow_reset` to `True` in your Settings() or include `ALLOW_RESET=TRUE` in your environment variables)

What it means

System.reset_state() (chromadb/config.py) cascades a destructive reset to every component in reverse dependency order, but only after checking Settings.allow_reset, which defaults to False. The guard makes resets explicitly opt-in so a stray client.reset() cannot wipe a production deployment. The message tells you the two ways to opt in: the allow_reset setting or the ALLOW_RESET=TRUE env var.

Source

Thrown at chromadb/config.py:479

        return sorter.static_order()

    @override
    def start(self) -> None:
        super().start()
        for component in self.components():
            component.start()

    @override
    def stop(self) -> None:
        super().stop()
        for component in reversed(list(self.components())):
            component.stop()

    @override
    def reset_state(self) -> None:
        """Reset the state of this system and all constituents in reverse dependency order"""
        if not self.settings.allow_reset:
            raise ValueError(
                "Resetting is not allowed by this configuration (to enable it, set `allow_reset` to `True` in your Settings() or include `ALLOW_RESET=TRUE` in your environment variables)"
            )
        for component in reversed(list(self.components())):
            component.reset_state()


C = TypeVar("C")


def get_class(fqn: str, type: Type[C]) -> Type[C]:
    """Given a fully qualifed class name, import the module and return the class"""
    module_name, class_name = fqn.rsplit(".", 1)
    module = importlib.import_module(module_name)
    cls = getattr(module, class_name)
    return cast(Type[C], cls)


def get_fqn(cls: Type[object]) -> str:

View on GitHub (pinned to aecdd12c8a)

Solutions

Construct the reset-capable client with the flag: chromadb.Settings(allow_reset=True) - restrict this to tests and local dev.
Or set the environment variable ALLOW_RESET=TRUE for the test/dev process only.
Never enable allow_reset in production; keep separate Settings objects for tests vs. deployment.

Example fix

// before
client = chromadb.PersistentClient(path='./data')
client.reset()  # ValueError: Resetting is not allowed

// after (tests/dev only)
client = chromadb.PersistentClient(path='./data', settings=chromadb.Settings(allow_reset=True))
client.reset()

Defensive patterns

Strategy: validation

Validate before calling

if not settings.allow_reset:
    # opt in explicitly - tests/dev only
    settings = settings.model_copy(update={'allow_reset': True})
system = System(settings)
system.reset_state()

Try / catch

try:
    client.reset()
except ValueError as e:
    if 'Resetting is not allowed' in str(e):
        raise RuntimeError('build the client with Settings(allow_reset=True) or ALLOW_RESET=TRUE (non-production only)') from e
    raise

Prevention

Give test fixtures their own Settings(allow_reset=True); never reuse production Settings for resets.
Gate reset calls behind an env check (e.g. only when ALLOW_RESET=TRUE) so they no-op in prod.
Prefer creating fresh persist directories per test instead of resetting shared state.

When it happens

Trigger: Calling chroma_client.reset() (which reaches System.reset_state) on a client built without Settings(allow_reset=True); test fixtures that reset between tests but reuse a production-ish Settings object.

Common situations: Pytest fixtures that call client.reset() without allow_reset=True; porting test helpers into prod-adjacent environments where the flag was dropped 'for safety'; notebooks that reset between runs.

Related errors

AI-assisted analysis of chroma-core/chroma@aecdd12c8a (2026-08-16). Data as JSON: /api/errors/b58676f53498ace4. Report an issue: GitHub.