The agent is leaving the chat window and moving into the operating system. OpenAI's new "Computer History" feature for the ChatGPT macOS app creates a searchable timeline of your actions by tracking clicks and keystrokes. This provides an agent with the context to act on your behalf, but its implementation—a local, unencrypted, plaintext database of your activity—is a security trade-off every builder should stop and consider.
Computer History uses the macOS accessibility framework to create a persistent memory of your actions. An OpenAI product and engineering manager described it as letting ChatGPT “learn from everything you do on your computer.” In practice, this means logging events like clicks, keystrokes, and application switches to build a timeline of your work. A demo showed the agent correctly identifying the last Google Doc a user viewed by searching through this history.
Control is a key part of the pitch. The feature is opt-in, not enabled by default. It reportedly ignores activity in private browsing tabs, and you can manually blacklist specific applications from being tracked. Users can also view the database of memories and remove specific items. For business accounts, an administrator must first enable the feature before individual users can opt in.
This is where it gets interesting for anyone who builds or uses developer tools. The memory files created by Computer History are stored locally as unencrypted plain-text Markdown. Any application or process running under the same user account could potentially read them.
This design choice prioritizes simplicity over security. While local storage avoids sending a raw, real-time feed of your every action to the cloud, the lack of encryption is a significant detail. Think about the sensitive information that crosses your screen: API keys, private messages, customer data, un-pushed code. A local plaintext log of the context around that information is a valuable target.
Here’s a hypothetical look at what a snippet of that memory file might look like, based on the feature's description.
## 14:30:05 - App Switch: Google Chrome
- **Action**: Viewed URL `https://console.aws.amazon.com/billing/home`
- **Keystrokes**: `[CMD+L]`, `billing`, `[ENTER]`
## 14:31:12 - App Switch: Slack
- **Action**: Viewed Channel `#dev-prod-alerts`
- **Context**: Read messages from @JaneDoe about deployment failure.
- **Keystrokes**: `[CMD+K]`, `prod-alerts`, `[ENTER]`
## 14:32:45 - App Switch: iTerm2
- **Action**: Executed command
- **Keystrokes**: `kubectl get pods -n customer-xyz-prod`
Seeing this structure makes the risk tangible. It's not just a chat history; it's a detailed log of your workflow that could be read by any other process with user-level permissions.
When an agent has access to your entire digital life as context, the blast radius for prompt injection expands dramatically. OpenAI's own documentation reportedly acknowledges the heightened risk. The feature is designed to pull context from your activity into future chats. If those chats are then used as training data (depending on your settings), a malicious actor could theoretically inject instructions into a Slack message or document that a future version of the model might act upon.
The line between user data and model instruction is blurring. An agent that can read your private Slack DMs could be manipulated by a message sent by a compromised account. This moves the security perimeter from the developer's machine to every single person and system they interact with.
This isn't just another feature. It is a real-world deployment of a persistent, OS-integrated agent, and it provides a critical lesson in the design of agentic systems. The trade-off between giving an agent enough context to be useful and preventing that context from becoming a security vulnerability is now a practical problem, not a theoretical one.
For now, the security burden of this architecture falls on the user. You have to trust that no other process on your machine will read the memory files and that the productivity gain is worth the risk of a new, potent attack surface. As we build and deploy more capable agents, we need to find better primitives for memory and context—ones that don't force this kind of choice between capability and security.