Two Screen Studio recordings from a C4C cohort session wouldn’t open. The folders were right there on the external drive - “terminal intro pt1” and “terminal intro pt2” - stuffed with 464 and 377 files respectively. Every fragment of the recording was accounted for: video segments, audio, cursor data, keystroke logs, webcam footage. But Screen Studio wouldn’t touch them.
The typical response to this is: Google the error. Maybe find a forum post. Maybe not.
Instead, Claude Code was asked to figure out what was wrong.
What the investigation looked like
The first step was just listing what was actually in the broken folders. The answer: hundreds of .m4s video segments, .m3u8 playlists, .m4a audio, a cursors/ directory with cursor images, metadata.json, and a handful of JSON files tracking keystrokes, mouse movements, and clicks. A polyrecorder.log at the bottom.
All the data was there. So why wouldn’t Screen Studio open it?
The next step was checking what a working .screenstudio file actually contains.
A .screenstudio file isn’t a file at all. It’s a macOS bundle - the same trick .app applications use. Finder shows it as a single file, but it’s actually a directory with a specific internal structure. Open one in the terminal and you find: meta.json, project.json, a recording/ subdirectory, and recording-markers.json.
Inside the recording/ subdirectory: the same .m4s segments, same cursors directory, same metadata format as the broken pt1 and pt2 folders.
The broken recordings had all the right content. They were just missing the wrapper.
The diagnosis
The pt1 and pt2 folders were “naked” recordings - the raw data that Screen Studio generates, sitting loose in a directory instead of wrapped in a bundle that the app knows how to read.
Screen Studio expects to open something named whatever.screenstudio. When it opens that bundle, it looks for meta.json at the root and a recording/ subdirectory containing the actual media. When both folders were created, the bundle wrapper never got written - only the recording data inside.
One more detail: the meta.json in a working bundle is simple. Just a version number, a required version, and a creation date.
The fix
Three commands per recording:
- Create a
terminal-intro-pt1.screenstudio/recording/directory - Move all the contents of
pt1/into thatrecording/subdirectory - Write a
meta.jsonat the root of the bundle with the version info from other Screen Studio projects on the same machine
Same thing for pt2. Both projects opened in Screen Studio on the first try. Screen Studio writes its own project.json when it opens a bundle for the first time - that file doesn’t need to exist beforehand.
Total time from “these won’t open” to “both are open in Screen Studio”: about ten minutes.
The pattern that transfers
Googling “Screen Studio won’t open files” would have eventually surfaced something - maybe. But the investigation that actually worked didn’t rely on someone else having the same problem and writing it up.
The pattern: look at a file that works, compare it to the one that’s broken, identify what’s different, add what’s missing.
Claude Code is good at this because the comparison is the whole job. List the broken folder. List a working bundle. Read the schema. Read the meta file. The diagnosis falls out of the diff.
Ten minutes of looking at actual files beat an hour of googling someone else’s problem.