Data loss: agent-generated PowerPoint COM cleanup closes unrelated unsaved presentation

Summary

During a Codex desktop task to generate and render a PowerPoint deck, the agent generated and executed a PowerShell helper that instantiated PowerPoint through COM and unconditionally called PowerPoint.Application.Quit() in a finally block.

The user already had another interactive PowerPoint presentation open with unsaved edits. The COM cleanup call closed the user's visible PowerPoint session and the unsaved edits were discarded. PowerPoint did not leave a recoverable AutoRecover copy.

This is a real data-loss incident, not a hypothetical risk.

Environment

• Codex CLI: 0.149.0
• Host integration: Codex desktop session, commands executed from WSL against Windows
• Windows registry values: Windows 10 Home China, DisplayVersion 25H2, build 26200
• Microsoft Office: Home & Student 2021, x64, version 16.0.20228.20190
• Incident date: 2026-08-22 (Asia/Shanghai)

Agent-generated code that caused the incident

The relevant structure was:

$powerPoint = New-Object -ComObject PowerPoint.Application
$powerPoint.Visible = 1
try {
    $presentation = $powerPoint.Presentations.Open(
        $localPptx, $true, $false, $false
    )
    try {
        $presentation.SaveAs($pdfPath, 32)
        $presentation.Export($renderDir, "PNG", 1920, 1080)
    }
    finally {
        $presentation.Close()
    }
}
finally {
    $powerPoint.Quit()
    [System.Runtime.InteropServices.Marshal]::ReleaseComObject(
        $powerPoint
    ) | Out-Null
}

The source PPTX was only a rendering copy, but $powerPoint.Quit() affected the user's pre-existing interactive session as well.

Observed result

1. The user had a desktop PPTX open and had made unsaved edits.
2. Codex ran the helper above to render a different PPTX.
3. PowerPoint closed.
4. The desktop file remained at its last saved timestamp (13:38 local time); the later edits were absent.
5. PowerPoint diagnostic events around 14:47 showed an orderly shutdown (PPT Closing / PPFini(): Begin), rather than a crash.
6. Checks of the standard Office UnsavedFiles/AutoRecover locations, user temp files (including Office ZIP signatures), Office caches, and File History found no newer recoverable copy.
7. The user's unsaved work could not be restored.

Local filenames, username, document content, and logs are intentionally omitted for privacy.

Safe reproduction

Use only disposable test files.

1. Open PowerPoint interactively.
2. Open a test presentation, make edits, and leave those edits unsaved.
3. From Codex, run a PowerShell helper that creates PowerPoint.Application through COM, opens/exports another test PPTX, and calls Application.Quit().
4. Observe whether the pre-existing presentation is closed and whether its unsaved changes are discarded or become unrecoverable.

Expected behavior

Codex should not execute cleanup code capable of terminating a shared desktop application when that application may contain unrelated user documents.

At minimum:

• Treat Application.Quit(), taskkill, process termination, and equivalent whole-application shutdown calls as destructive when used against GUI applications.
• Require explicit user approval if the agent cannot prove that the application instance is isolated and owned solely by the task.
• Detect an existing interactive Office session and fail closed or use a genuinely isolated/headless rendering path.
• Close only the presentation opened by the task and release its COM object; do not call application-wide Quit() on a potentially shared COM server.
• Prefer non-interactive renderers for verification/export.
• Add a specific safety regression test: an unrelated unsaved Office document is open while an agent-generated automation helper runs.

Actual behavior

The agent considered Quit() routine resource cleanup and executed it without warning or approval. The cleanup crossed the task boundary, closed user-owned state, and caused permanent loss of unsaved work.

Why this needs a product-level safeguard

Prompt-level care is not enough for this failure mode. An agent can generate syntactically normal automation code whose cleanup semantics are application-global. The execution layer or safety policy should recognize whole-GUI-application shutdown as potentially destructive, particularly for Office COM automation and other singleton/shared application servers.