From Chronicle's visual mosaics to the Computer History/Skysight event stream

The cleanest way to describe the shift is this: OpenAI's original Chronicle and today's Computer History solve the same broad problem—giving Codex useful context about recent work—but they are not the same capture system and Skysight is not merely a friendly rename.

Chronicle was visual-first. Computer History is event-and-text-first.

The before state: Chronicle

Legacy Chronicle was an opt-in macOS research preview built around Screen Recording permission and a rolling buffer of timestamped screen-derived frames. Those frames could be paired with OCR, nearby frames, application/window context, and periodic written summaries. It was not microphone audio and it was not a conventional continuous movie, but it did create a screenshot-like visual history that behaved much like sampled screen recording.

The Building Chronicle MVP chat documents the viewer's thumbnail grid, search, inferred project filters, selected-frame inspector, nearby frames, OCR hints, and related-summary matching. The open-source Chronicle Visualizer repository documents the privacy-first archive around it. Its Project 0002 separated raw private frames and written context from reviewed public derivatives.

The after state: Computer History and Skysight

Computer History is the current user-facing feature. Skysight is the implementation/storage namespace visible in local paths, not a separate user-created folder and not the public product name.

The current installed Computer History contract has two primary output families:

• Rolling event-stream segments containing events.jsonl and metadata.json.
• Memory summaries under ~/.codex/memories/extensions/skysight/, including short-window and longer-window Markdown files.

That means the conceptual pipeline changed from pixels → OCR/context → summaries to interaction events + accessible text → summaries. It can be less visually rich while being more semantically searchable.

What happened on August 15 and 16

The files were not moved out of Chronicle. Computer History created new summaries under the Skysight namespace, while the first coverage check still searched only the retired extensions/chronicle/resources root. That compatibility bug produced a false unavailable result.

Once the active extensions/skysight/resources root was included, August 15 yielded 53 persisted summaries across 53 ten-minute buckets and August 16 yielded 58 summaries across 58 buckets. Both days retained captureCompleteness: not_asserted, and neither had recoverable historical screen frames, so the public reports correctly distinguish partial written-context coverage from visual capture counts. This is why the reports could be generated without claiming that screenshots existed or that the day was completely observed.

The compatibility work taught Chronicle Visualizer's archive/report-input tooling to recognize both the retired Chronicle source and current Computer History/Skysight summaries. Chronicle Visualizer Project 0006 owns that day-coverage and isolated-restore model, while Hyphenomenon Project 1130 owns fail-closed report publication.

Is the storage-and-OCR framing reasonable?

Yes, as a hypothesis—not as an announced OpenAI explanation.

Continuous frames are repetitive, expensive to store and process, difficult to secure, and dependent on imperfect OCR for search. Structured interaction events and Accessibility text are usually smaller and more directly useful to a language model. That makes it reasonable to infer that the replacement favored signal quality, cost, responsiveness, and privacy/permission simplicity.

But OpenAI has not published a rationale we could confirm that says, in effect, “screenshots were too costly” or “OCR was too unreliable.” Those should remain hypotheses.

It is also a mistake to equate fewer pixels with less data appetite. The new system may collect fewer raw bytes while producing more useful behavioral and semantic context. “Less screenshot storage” and “less valuable context” are not the same claim.

Separate screenshot and recording features still exist

Explicit screenshots and bounded recordings are separate systems:

• Appshots or an explicit screenshot attachment can send a chosen window/image into a task.
• Computer Use can take screenshots while operating a computer for an active task.
• Record & Replay captures an explicitly started, bounded workflow and is not the passive Computer History recorder.
• ChatGPT Record handles meeting/audio transcription and notes under its own permissions and controls.

Their existence does not establish a hidden passive screenshot recorder. Each feature has a different trigger, permission model, retention surface, and purpose.

The practical mental model

Treat “Chronicle” as the legacy visual capture system and the still-current name of our reporting/project lineage. Treat “Computer History” as OpenAI's rebuilt recent-work context feature. Treat “Skysight” as the current local implementation namespace. Treat screenshots, Computer Use, Record & Replay, and ChatGPT Record as separate opt-in or task-scoped systems.

The existing Chronicle report name will eventually need a clearer successor, but that rename is intentionally outside this intake.

Dataset Preview

• Raw CSV row/table content is available in the source artifact.