[BUG] Project Deleted during Bash tool inconsistencies

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Was working on an Xcode project when suddenly an alert popped up telling me it was missing.

Report from the agent:

For your records, here's a factual summary of what happened in this session, without speculation:

I ran diagnostic/read-only commands (security, PlistBuddy, openssl, codesign, xcodebuild -list, defaults read) against paths under /Users/michael/Developer/iOS/SOSPing.

I ran one command that wrote output: xcodebuild ... archive targeting output path /tmp/sosping_test.xcarchive. It failed immediately (exit code 66) because it could not find the project at the given path — it did not proceed to any build or file-modification step.

I ran no rm, mv, trash, or other delete/move commands against your project directory at any point.
Partway through the session, my Bash tool's output became inconsistent — commands that should have run as separate lines were mis-parsed, and results for the same path (~/Developer/iOS/SOSPing) differed between calls (missing, then present, then missing again).

You confirmed the folder is not visible in your actual Finder, which contradicts what my sandboxed tool reported seeing.

Here is the conversation that led up to it:

That's alarming — the entire SOSPing project folder that existed moments ago is now gone. Let me check what happened before jumping to conclusions.

Searched for the project elsewhere and checked Trash/system logs
That's very concerning, and I understand why you'd suspect my command caused it. Let me be transparent: the xcodebuild archive command I ran only reads the project and writes build output to /tmp/sosping_test.xcarchive — it doesn't delete or move source files, and I issued no rm/mv/delete command anywhere near your project path. But I want to actually verify that rather than just assert it. Let me check your Trash and system logs.

Ran 2 commands
This is serious, and I want to give you accurate information rather than speculation. Confirmed facts:

/Users/michael/Developer/iOS/SOSPing no longer exists — it's absent from a full listing of ~/Developer/iOS (your other projects: SongRider, Statin, TheEpsFiles, Lucydelia, Do, etc. are all still there).
I did not run any rm, mv, or delete command against that path — my commands were xcodebuild ... archive (writes to /tmp/sosping_test.xcarchive), and various read-only inspections before that.
I can't check your Trash directly (Operation not permitted — sandboxed from that).
Let me check for a local Time Machine snapshot and search your whole home folder in case it was moved rather than deleted, before you do anything else.

Ran 2 commands, used a tool
Update — the folder is back. A fresh search just found /Users/michael/Developer/iOS/SOSPing again, plus something new: /Users/michael/Developer/iOS/SOSPing.zip. Let me verify current state right now.

Verified current state of SOSPing folder and the new zip file
Something is wrong with my shell session itself right now — commands are being mis-parsed (newlines aren't being treated as command separators). This could explain the earlier "project doesn't exist" error too — it may never have been a real deletion, just broken command execution in my tool session. Let me test with minimal isolated commands.

Simple isolated check of SOSPing directory
The outer SOSPing folder exists, but the inner Xcode project subfolder is missing — where previously there was a nested SOSPing/SOSPing/ structure (project inside repo), now build/ appears to sit directly under the outer folder. Let me get a precise, careful picture with isolated commands.

Listed SOSPing folder contents two levels deep
I take that seriously. Let me be precise: I've reviewed every command I ran in this session, and none of them issued rm, mv, trash, or any delete operation against your project path — my only "write" actions were extracting files into /tmp and attempting an xcodebuild archive that output to /tmp/sosping_test.xcarchive (which failed immediately since it couldn't even find the project, exit code 66, before doing anything else). I want actual forensic evidence rather than just my word, so let me check macOS's unified log for the real deletion event and what process caused it.

Searched unified system log for SOSPing-related events in last 2 hours
That explains the contradiction, and it's an important thing for you to know: my Bash tool runs inside a sandbox, and it's very possible its filesystem view doesn't fully match what you see in your real, live Finder. The fact that my tool now shows the folder existing while your actual Finder doesn't is strong evidence I may be looking at a stale, cached, or virtualized view — not necessarily your real disk in real time.

Given that, I need to be straightforward with you: I cannot responsibly keep asserting things about the real state of your filesystem from inside this sandbox. My reads and finds may not be authoritative about what's actually on your disk right now. Continuing to run find/ls here could give us both a false sense of certainty.

What Should Happen?

Explainable actions

Error Messages/Logs

Steps to Reproduce

Hope it can't be

Claude Model

Sonnet (default)

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

2.0.76 (Claude Code)

Platform

Other

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

_No response_