Prototype instance cleanup behavior in long-running CLI processes

Direct answer

No documented TYPO3 pattern defines a per-logical-request reset for prototype objects in a persistent CLI command, and Extbase is built around a single request/response cycle. There is no publicly confirmed plan for an automatic per-cycle CLI cleanup hook in a future release. The ObjectManager also does not guarantee that all internal references to a prototype disappear the moment the caller releases its own reference; container or registry references may remain until the container is cleared or the process ends.

Confirmed facts and uncertainty

The changes associated with TYPO3 10.4.14 and 11.5.2 stop prototype-scoped objects from being retained in the singleton cache solely because they were created. Those versions are end of life, so the fix is version-specific and must be verified against the installed source and changelog. After the change, prototype instances are not cached by creation alone, but no general contract guarantees that every internal reference is gone once user code releases its reference.

Steps for this case

1. Keep prototype dependencies in the narrowest local scope of each logical cycle and do not assign them to singletons, static properties, or global state.
2. Unset the dependency variable at the end of the cycle to release the caller's reference.
3. If memory growth persists, inspect the installed TYPO3 version and source for ObjectManager::reset() or an equivalent container-clearing method before using it; a reset may also discard singletons, persistence state, or injected dependencies needed later in the same process.
4. Implement any cycle boundary in your command wrapper rather than waiting for framework support.

Verification

Run a read-only source check against the installed version:

grep -n 'reset' typo3/sysext/extbase/Classes/Object/ObjectManager.php

grep -n 'prototype' typo3/sysext/extbase/Classes/Object/ObjectManager.php

Then compare memory behavior in a throwaway CLI loop that creates the same prototype repeatedly, logs object identity and memory_get_usage() after releasing the variable, with and without a verified container reset. Use reflection only in a disposable test script; never depend on private container keys in production code.

Missing diagnostic detail

What TYPO3 version is installed? This determines whether the 10.4.14/11.5.2 behavior applies and whether reset() exists, which changes whether a container reset is a viable step between logical cycles.

Assumptions and uncertainty: The referenced patch is unverified for your installation. Long-running CLI memory growth can also come from static registries, database connections, or Extbase persistence unrelated to prototype objects. Treat future roadmap statements as unconfirmed.