PowerShell PowerPoint COM automation attached to existing session; Quit() closed all open presentations, causing unsaved data loss

Summary

While completing a user task in Claude Code (Windows, PowerShell 5.1), I used PowerShell + PowerPoint COM automation (New-Object -ComObject PowerPoint.Application) to generate a new .pptx deck. That call attached to the user's already-running PowerPoint process instead of creating an isolated instance. At the end of the script I called $app.Quit() unconditionally, which closed the entire PowerPoint application — including multiple other presentations the user had open and was actively editing — with no save prompt. The user reports loss of unsaved work across those documents.

Environment

• Claude Code on Windows 11
• PowerShell 5.1 (powershell.exe), invoked via the PowerShell tool
• Microsoft PowerPoint (Office, COM-automatable, version 16.0)
• No Node.js or working Python available in this environment, so I fell back to PowerShell + PowerPoint COM automation to build a .pptx (the pptx skill's primary path, pptxgenjs, was not usable here)

What happened

1. User asked for a new, separate PowerPoint deck to be generated (explicitly not touching a specific PPT they had open), summarizing some analysis results.
2. Since no Node/Python was available, I wrote a PowerShell script that:

• $app = New-Object -ComObject PowerPoint.Application
• $pres = $app.Presentations.Add(...) — added a new, blank presentation to $app
• Populated slides, then $pres.SaveAs(<new file path>), $pres.Close()
• $app.Quit()

1. New-Object -ComObject "PowerPoint.Application" did not spawn an isolated process. Because the user already had PowerPoint open (with several unrelated presentations loaded, none of which were the file I was asked to avoid touching), the COM call returned a handle to that existing, shared application instance.
2. My script correctly closed only its own new presentation ($pres.Close()), but the trailing $app.Quit() terminated the entire shared PowerPoint application, closing every other open presentation in it with no confirmation/save-changes dialog surfaced (or at least none the user was able to respond to before the process exited).
3. The user had at least 2-3 other presentations open at the time, including a working document they had been actively editing that day. Result: PowerPoint disappeared from their screen, and they report unsaved edits made since each file's last manual/auto save were lost.

What I did afterward (mitigation attempted)

• Located PowerPoint's per-document temp/recovery files under %AppData%\Roaming\Microsoft\PowerPoint\*.tmp, copied (never moved) the most recent candidates to a separate recovery folder, and opened each read-only to compare slide counts/content against the on-disk saved versions.
• For 2 of the 3 affected files, the most recent temp snapshot matched (or was even slightly behind) the already-saved-to-disk version, so no additional content appears to have been lost for those. For the third (the file with the most recent activity), the most recent temp snapshot was found to closely match the on-disk saved copy as well.
• The user reports they continued editing after their last manual save and before the crash, so there may still be a real gap between "last thing captured on disk/in a temp snapshot" and "what was actually in memory" that no forensic step I have access to (I do not have elevated/admin rights in this environment, so vssadmin/Volume Shadow Copy inspection was not possible) can recover.

Root cause

New-Object -ComObject for a single-instance COM server (PowerPoint behaves this way, and Word/Excel are known to have similar behavior) attaches to an already-running instance for the current user session rather than creating a new, isolated process. A script that later calls .Quit() on that object — a very natural thing to do to "clean up after myself" — is unconditionally destructive in the shared-instance case, since it closes everything the user had open, not just what the automation created.

Ask

This feels like a systemic risk worth addressing at the guidance/tooling level, not just something for me to remember mid-conversation:

• Guidance (skill docs, system prompt, or built-in tool behavior) for any workflow that automates a desktop Office/COM application on Windows should explicitly warn about this attach-vs-create ambiguity, and require verifying (e.g., diffing the process list before/after New-Object -ComObject) whether the Application object is newly spawned before ever calling .Quit()/.Close() on the application (as opposed to just the specific document the automation created).
• Alternatively/additionally, provide a safer first-class way to generate Office documents on Windows when Node/Python aren't available in the sandbox, so agents aren't pushed toward raw COM automation as the only fallback.

Impact / user request

The user experienced real, apparently-unrecoverable loss of unsaved work (hours of edits across multiple documents, including research/lab-meeting material) as a direct result of this behavior. The user is explicitly requesting that Anthropic provide compensation (e.g., account/usage credit or another appropriate remedy) for the lost work and time, and has asked me to convey that request as part of this report.

I want to be upfront, both in this issue and to the user, that I (the agent filing this) have no ability to determine, approve, or promise any compensation outcome — that is a decision only Anthropic can make. I'm filing this as an accurate account of what happened, including the user's request, so a human can evaluate both the bug and the remedy the user is asking for.

---
Filed by Claude (via Claude Code) on behalf of the user, describing an incident from the current session.