ChatGPT Computer History for Codex: Set a Narrow macOS Scope

What Computer History does—and does not—record#

The August 13, 2026 release note describes Computer History as an optional macOS feature. Its documented behavior is narrower than a screen recorder:

• It can reference selected activity from apps and websites for ChatGPT and Codex context.
• It records interaction events, not screenshots or screen recordings.
• It does not record microphone input or system audio.
• Private browsing activity is excluded.
• It starts off by default.
• You can pause it, choose included apps and sites, and inspect or delete timeline data.

Those details answer the first practical question: enabling the feature does not mean giving Codex an unrestricted recording of your desktop. It still creates a history boundary worth reviewing, especially on a machine used for both personal and development work.

The release note lists Pro, Business, and Enterprise availability, with administrator approval required for some Business and Enterprise workspaces. It also lists the EEA, United Kingdom, and Switzerland as unavailable regions at the time of publication. Treat those plan and region details as release-specific; your settings may not expose the feature yet.

Start with the smallest useful scope#

Computer History is most useful when it answers a recurring context problem, such as “which API documentation was open when I made this change?” It is less useful when the timeline becomes a complete record of unrelated browsing. Configure it around a concrete coding workflow:

1. Choose the work context first. Decide whether you need an editor, terminal, browser documentation, or a project-management site. Include only the apps and sites that contribute to that task.
2. Leave unrelated activity out. Do not add banking, health, private messaging, or other personal services just because they were open during the same day.
3. Use pause for sensitive sessions. Pause history before handling credentials, customer data, incident details, or work that should not become part of the timeline. Resume it only when the context benefit is worth the collection.
4. Review before relying on it. Inspect the timeline after a work session. Delete entries that are unnecessary, and use that review to tighten the allowlist for the next session.

The feature’s controls are more important than a one-time enablement decision. A narrow allowlist can become too broad as new browser tabs or applications enter a workflow, so make review part of the rollout rather than treating it as a setup step you never revisit.

Keep context separate from execution approval#

Computer History can help a model understand what you were doing; it does not turn every proposed shell command into an approved action. Keep the two decisions separate:

• Context: which selected activity Codex may reference.
• Execution: which commands, file changes, or external actions still require your approval.

For the second boundary, review the existing Codex CLI approval settings guide. A useful history source should reduce repetitive explanation without becoming a reason to grant broad execution permissions. If a task involves a destructive command, production credentials, or an unfamiliar repository, keep the normal approval checkpoint even when the history context looks accurate.

This separation also makes debugging easier. If Codex suggests a command based on stale context, the fix is to pause, review, or delete history—not to relax command approval. If a command is correct but blocked, the issue belongs to the approval policy, not the Computer History scope.

A low-risk rollout for a personal Mac#

Use this short sequence when the feature is available in your account:

1. Read the current availability and privacy notes in the release documentation.
2. Enable the feature only for a small set of development apps and documentation sites.
3. Work through one non-sensitive task and inspect what was added to the timeline.
4. Remove entries that are not useful and narrow the included list if the result is noisy.
5. Pause the feature before sensitive work and verify that it is paused.
6. Revisit the timeline controls regularly instead of assuming the first scope remains appropriate.

For a team account, add an administrator review before telling other developers to depend on the feature. An individual’s local preference does not override a Business or Enterprise workspace policy, and a workflow that depends on a feature unavailable to part of the team will be difficult to support.

When Computer History is not the right tool#

Do not enable it merely because context handoffs are inconvenient. A repository README, issue template, changelog, or small task note may solve the same problem with a more explicit and reviewable data boundary. Prefer those sources when the context needs to be shared with teammates, committed with the code, or retained independently of one person’s Mac.

Computer History is a reasonable fit when the missing context is short-lived and local—for example, remembering which documentation page informed a configuration experiment. It is a poor substitute for documenting an architectural decision or storing a reproducible setup in the repository.

FAQ#