Deleting a T3 thread leaves its native provider conversation intact #29397

Problem

Deleting a conversation in T3 Code leaves the corresponding native provider conversation behind. I deleted a T3-created Codex chat in T3, but it remained visible in the Codex desktop app. Users who delete a conversation to remove its contents therefore still have a separate, resumable copy outside T3.

This report is specifically about provider-side history. #17845 already tracks the separate problem that T3's own database retains deleted-thread content; #24924 proposes correcting the confirmation text. Neither provides deletion of the native provider conversation.

Steps to reproduce

1. Create a disposable chat in T3 using the native Codex provider and send a message.
2. Confirm that its native conversation is present in Codex using the same Codex home.
3. Delete the chat in T3.
4. Check Codex again: the conversation is still present.

Observed on Windows using the T3 and Codex desktop apps. The exact installed T3 version at the time of the original observation was not recorded. The source investigation used main at 333f7a6f6e6b074ba28aca662ff4052c99280d15.

Source findings and limits

• ThreadDeletion.ts records the T3 deletion, cancels work, detaches provider sessions and schedules resource cleanup.
• ResourceCleanupService.ts cleans resources such as attachments and terminal history; it does not purge native provider conversations.
• The native Codex adapter unloads through thread/unsubscribe, rather than deleting the native thread. Disconnecting a runtime does not erase its stored conversation.

The directly observed cross-app symptom was Codex. Claude Code stores a separate native transcript too, but I have not repeated the T3-delete test across every provider. This report is not a claim that all providers offer the same deletion API or storage guarantees.

Desired outcome

Provide an explicit, confirmed way to delete a T3 chat's associated native provider conversation as well as the T3 content covered by #17845. Whether this belongs in the existing Delete action or a separate "delete everywhere" option is a product decision for maintainers. At minimum, the confirmation/result should make retained provider history clear.

For a provider-aware deletion path:

• Target the recorded native session identity and the correct provider instance/home on the environment that owns it; do not purge an entire provider project or unrelated CLI/desktop sessions.
• Account for native sessions referenced by other T3 threads, imported conversations, forks and provider switches before removing shared history.
• Use a supported provider deletion API where available. If a provider cannot safely delete its native history, report that limitation rather than claiming complete deletion.
• Report partial failures and allow an appropriate retry. The result should distinguish T3 cleanup from provider cleanup.
• Keep project source files outside this conversation-deletion scope. This is about native conversation history, not cloud-provider retention policies or forensic secure erasure.

I searched issues, PRs and discussions for native-session deletion and did not find an existing report covering this end-to-end behavior. #27771 adds ACP delete-capability handling, but is not a general T3-chat-to-native-session deletion workflow. If this should be routed to Ideas as a product proposal, please move it there; it is intentionally separate from the existing database-retention issue.

Filed by Codex on behalf of @CanePlayz, at their explicit request. No deletion implementation or private conversation data is included.