A decision inside the running session
While a coding agent is running, disabling usage measurement makes a narrower request than deleting its conversations: stop sending usage events from this point onward. OmO Native’s October 17 disclosure describes that request going unenforced until the session ended. In versions 5.0.0-beta.6 through 5.1.34, changing the setting during a running session did not stop the event stream. A consent switch offers little practical control when revocation does not reach the sending path. The question here is when the user’s decision to stop takes effect, after the interface has already accepted that decision.[1]
The disclosure draws an important boundary around the data. The developer identifies completed turns, feature use and activation of computer control among the confirmed events, while allowing that other usage events may have followed the same path. It also says those events contained no prompt or response text, file paths or file contents. That does not support an allegation that conversations were leaked. A usage event without conversation text can nevertheless be data the user has chosen not to send. The scope of the contents and permission to transmit them create separate responsibilities.[1]
From sending to erasure
Version 5.1.35 checks consent again where an event is sent. A check may be reused for at most 5 seconds; once the opt-out is read, queued events are discarded. A session that begins opted out creates no session hash, salt, notice marker or summary file. Configuration and environment-based opt-outs share the check. This moves the decision from a startup preference to a condition on the continuing data flow. The five-second reuse limit also matters: it describes bounded latency rather than an instantaneous response. The claimed repair is specific enough to distinguish those behaviors.[1]
Stopping future transmissions and erasing earlier ones require different workflows. The developer says events sent after an ineffective opt-out cannot be distinguished from events sent with consent. Deletion is therefore offered at installation level. The user must supply the installation identifier through private vulnerability reporting, rather than posting it in a public issue. This targets a broader set of data instead of reconstructing each event’s consent history. Usage measurement can serve a legitimate purpose, but an inability to distinguish permission states later makes the remedy less precise. A repaired sender cannot by itself supply the missing history.[1]
The burden of older identities
Older machine identifiers explain why erasure cannot be reduced to a switch. New events use a hash of the installation identifier, while the old machine hash accompanies them until December 14 to join earlier data. The developer can erase older events together only when that hash maps to the installation and no other. Shared histories need an additional ownership showing. That requirement can burden the requester. Its strongest alternative justification is protecting another person’s data where a common identifier spans installations. Installation-level identity narrows this conflict; it does not automatically repair old mappings or establish who owns every older event.[1]
The useful disclosure here describes both what was not collected and the remaining path to erasure. A user can identify which transmissions the new version stops, which identifier an older-data request needs and where to send it privately. My consent test extends beyond a switch appearing disabled: the sender must read the revocation, and retained events need an erasure path that reaches their owner. OmO Native’s account makes those two stages concrete. It also leaves the ownership limits of older shared histories visible. The repair becomes assessable through that specificity, without treating its boundaries as already resolved.[1]