Computer history

Computer History records activity in the Mac apps you choose and summarizes it so Fermix can answer questions such as “What was I working on this morning?” It is off by default and separate from computer use, which controls the desktop.

Native helper availability: the daemon currently requires a newer capture protocol than its pinned public helper download provides. That download cannot start capture. A Fermix build that pins a matching helper is needed; reinstalling the same download does not resolve a protocol mismatch. The controls and behavior below describe the implemented feature once the helper matches.

What it records

Capture is limited to an app allowlist. No app is recorded until you select it. In an allowed app, Fermix records app activity, focused-window titles, and the settled values of editable Accessibility fields. It does not take screenshots, record audio, or log individual keystrokes. Capture starts when enabled; it cannot recover activity from before that point.

Browser capture is limited to window titles. The driver withholds browser field text and does not emit page URLs or navigation events. The sites setting therefore does not currently filter browser activity: there is no page host for it to match. Allowlisting a browser permits its window titles, not just titles from selected sites.

Password fields are suppressed, and a scrubber removes recognized secret patterns before storage. This cannot guarantee that sensitive text is excluded: a code or token pasted into an ordinary allowed text field can still be captured. Select apps with that in mind. Fermix’s own browser and desktop actions are not yet excluded from capture, so recorded activity can include actions the agent performed.

The recorder requires macOS Accessibility access. The downloadable Mac helper supports Apple Silicon; Intel Macs and non-macOS hosts cannot use Computer History through that installer.

Enabling it

1. Run fermix setup, open the setup page, and select Plugins.
2. Find Computer History and choose Enable.
3. Select the apps to record from the searchable list. Saving an empty selection is refused.
4. Complete the native-helper installation and use Grant to give it Accessibility access in System Settings.
5. Apply the settings and restart when setup requests it. Run fermix doctor and read its computer history row to check capture and summarization.

The card shows how many apps are selected. Edit apps changes the allowlist, and Disable stops the feature. Enabling is a setup action; chat commands can inspect, pause, delete, or turn it off.

Before enabling, check where summaries will be produced. The default sends captured activity to the configured summarization provider. Choose the local route explicitly if the raw activity must stay on your Mac.

Where the data goes

The [fermix_core.computer_history] section controls capture and provider access:

Key	Default	Meaning
enabled	false	Enable capture and activity recall.
apps	[]	Allowed app bundle IDs. Setup lets you select apps by name.
sites	[]	Allowed website hosts when capture supplies a host. The current browser capture does not supply one.
summarizer	"default"	Where raw activity is summarized: "default", "local", or one provider ID.
remote_summaries	[]	Providers allowed to receive derived activity summaries in chat or voice.

With summarizer = "default", Fermix uses your sub-agent provider, model, and reasoning settings when configured, otherwise your primary provider. Raw activity goes to that provider to produce summaries. While this route is active and history is enabled, its resolved provider is also allowed to receive those summaries in conversation.

With summarizer = "local", summarization uses Ollama on loopback. Raw activity stays on the Mac. An Ollama endpoint on another machine is remote and does not satisfy this setting.

With a named summarizer, such as summarizer = "anthropic", raw activity goes only to that provider. Summarization never fails over to another provider. Granting permission to summarize raw activity does not itself grant conversational recall on that provider; use remote_summaries for that permission.

For example, this keeps summarization local while allowing Anthropic to receive the resulting summaries:

[fermix_core.computer_history]
enabled = true
apps = ["com.apple.TextEdit"]
summarizer = "local"
remote_summaries = ["anthropic"]

This requires a configured, running local Ollama model and the native helper. Edit summarizer and provider grants in config.toml, then restart; they are separate from selecting apps in setup.

Every provider in the conversation’s possible route chain must be local or granted. An ungranted remote provider anywhere in that chain hides both activity recall and the prompt digest for the turn. For example, if the default summarizer runs on a different provider from your main conversation, that main provider needs its own grant. Grants apply to providers, not individual models.

History can also appear in content-capturing traces. The history provider grants do not control trace export. If you configure a remote Opik endpoint, its normal content-capture settings can send history there.

Asking about your activity

Activity recall is available only to the owner in an attended conversation, including an eligible live voice call. Guests, sub-agents, scheduled jobs, and other unattended runs do not receive it.

Fermix adds a Recent Activity digest containing up to eight dated summaries from the last 24 hours. For an explicit question, recall_activity supports today, yesterday, this_morning, this_afternoon, this_week, and recent (the last four hours). It defaults to today.

Both surfaces return derived summaries, not raw field values, dated in your configured timezone. Recall shows newest entries first and reports how many entries it displayed out of the total for that window. A narrower window can expose entries omitted from a larger result.

Summaries are produced about every 30 minutes, so new activity is not immediately available. Each summarized batch creates its own memory. The summarizer can skip a batch with nothing worth remembering and redacts detected verbatim runs of source field text from its proposed notes. This redaction is a backstop, not a guarantee that every sensitive fragment will be detected.

Activity is treated as untrusted data. Replies derived from it retain an origin marker so conversation replay, compaction, and skill curation can withhold them from ungranted providers. Turning history off does not remove that protection.

Status, pause, and deletion

These commands are owner-only:

Command	Effect
/history status	Show capture, summarization, allowlists, stored activity, unsummarized backlog, and agent-read counts.
/history pause 10m	Pause capture for ten minutes, then resume automatically. 1h and 24h are also supported. The pause survives a daemon restart.
/history purge 24h	Delete raw events in the window and activity summaries whose source windows overlap it. Also accepts 10m, 1h, or all.
/history off	Stop capture and hide recall from the next turn. Re-enable in setup to reuse the same allowlist.

Pause and purge durations accept a number followed by m or h. A pause does not delete earlier activity or prevent recall of existing summaries.

Raw events have a 48-hour retention window, enforced by an hourly sweep, plus a 64 MiB content-size ceiling that removes the oldest events if reached. Cleanup continues while the feature is disabled. Derived summaries remain until purged; disabling does not erase them.

Every successful recall_activity read, including an empty result, and every non-empty Recent Activity digest records a metadata-only audit entry: when it was read, which surface read it, its window, and the result count. /history status reports the count and most recent read. The newest 10,000 audit rows are retained, and purge removes audit rows recorded within the purged window.

Purge is logical deletion. It removes rows from queries, but bytes can remain in the database until overwritten. It cannot erase delivered replies, copies already sent to providers, backups, or another daemon’s store. Activity is kept in dedicated tables in memory.db, separate from general memories.

Related pages

• Computer use: desktop control and the shared native helper.
• Configuration: configuration keys.
• Memory: general memories and conversation history.
• Tool reference: activity recall parameters.