Can an AI SRE read my Claude Code sessions as context?

Yes, Tares ingests your Claude Code session transcripts through the Tares plugin, so an AI SRE can query them and correlate what your agent did with what your systems did. Each message is stored as one event in the claude_code source, keyed by session. Redaction of obvious secrets and tokens is on by default and runs on the server before anything is stored.

How it works

The Tares plugin for Claude Code ships each session’s transcript to the Tares daemon over HTTP as the session progresses. It works the same against a local or a remote daemon. The Claude Code connector turns the transcript into events in a single push source named claude_code.

• One event per message. Each event is keyed by session. Sub-agents roll up into the same source.
• Labels you can filter on. session (the key), project, branch, model, type (the message type) and sidechain (sub-agent messages). Token-usage fields come with the events.
• Capture hooks. Hooks send new transcript lines to /ingest/claude_code on each prompt, tool use and session end. The plugin creates the push source on the daemon the first time it runs, so you add no source by hand.
• Redaction. The redact field is true by default and removes obvious secrets and tokens. It runs server-side in the connector, so it applies before anything is stored. Set it to false to turn it off.
• Thinking blocks. include_thinking is false by default. Set it to true to include assistant thinking blocks in the rendered text.
• Read-back. The same install connects the session to the Tares MCP endpoint over HTTP, so the agent can read the data plane too, including its own history.

The claude_code source is one source among the others you connect. An AI SRE works from that shared data, so session events can be read next to your metrics, logs and alerts.

Set it up

1. Install the plugin in Claude Code. The console also has a one-click page under Sources, Add source, claude_code, which shows the install command wired to your instance’s URL.

/plugin marketplace add glassflow/tares
/plugin install tares@tares

2. Answer the install prompts:
   • Tares URL: the daemon’s base URL. The default http://127.0.0.1:8787 matches tares up.
   • MCP endpoint: where the session reads Tares over MCP. Locally, keep the default http://127.0.0.1:8788/mcp and run tares mcp with the streamable-http transport next to tares up. On Tares Cloud there is nothing to start.
   • Access token (optional): only on a secured instance. Use a read + ingest API key so the plugin can both stream sessions and read back over MCP. It is stored in the OS keychain.
   • Stream this session into Tares: the capture toggle, on by default.
3. On Tares Cloud, you can skip copying a URL or key. With the tares CLI installed (1.45.0 or later, plugin 0.5.0 or later), sign in and pick your workspace in the browser:

tares login

This machine gets its own key on that workspace, and the plugin picks it up. The one setting left is the MCP endpoint. Set it to the address tares login prints, which ends in /mcp on your workspace host. In Claude Code, run /plugin, pick tares, then Configure. A Tares URL or Access token you set by hand wins over the login. 4. Verify. Start a Claude Code session and do some work. In the console, Explore lists sessions under the session key, and the source’s Recent events shows messages as they ship. With the plugin installed you can also ask:

Use tares to show me my current session’s timeline.

Capture is forward-only. Sessions stream from the moment the plugin is installed, and transcripts already on disk are not backfilled.

What you get

• Your Claude Code work is queryable data. Every message is an event with its project, branch, model and token usage.
• You can line up what an agent did with what your systems did, because the session events sit in the same data plane as your other sources.
• Obvious secrets and tokens are redacted on the server before storage by default. Treat this as a filter for obvious credentials, not a guarantee that nothing sensitive is ever stored, and keep thinking blocks off unless you need them.
• The agent can read back its own history through the same install, with no extra MCP process started by the plugin.
• Sessions marked as challenger sessions carry a flow label from the mark onward, plus events such as challenge_plan, challenge_commit and session_end, with labels like verdict and round.

When something else fits

• If you need history from before the plugin was installed, this connector does not help, because capture is forward-only and existing transcripts are not backfilled.
• If you want a different kind of context, such as metrics or logs, use the connector built for that data and keep claude_code for agent activity.

Related