Claude Code visibility

Claude Code session monitoring: see every tool call in real time

If you have ever wondered, “claude code what is my agent doing?”, this is the missing layer. I wanted a simple way to monitor Claude Code agent behavior locally, in real time, without guessing which tools fired or what happened during a run.

I started looking for a practical answer to claude code session monitoring after a few runs where Claude Code clearly did a lot of work, but I could not see enough of it while it was happening. I was running Claude Code and had no idea what it was actually doing. The agent would pause, call tools, touch files, and eventually produce an answer, but my view into the session was incomplete. If you are trying to monitor Claude Code agent behavior during autonomous work, that gap becomes a real problem fast.

The issue is not that Claude Code is unusable. It is that autonomous agents compress a lot of actions into a short period of time, and once you let them operate with some freedom, you need observability. You need to know which tool was invoked, what arguments were passed, when it happened, and what the overall session looked like when it ended. Without that, debugging becomes guesswork. Governance becomes guesswork too.

That is the core problem: Claude Code agents can run autonomously, but there is no built-in session monitoring layer that gives me a complete local trace. I cannot natively inspect every tool event in one place. I cannot easily answer basic questions like which tools fired, what files were touched, or how many tokens were consumed across a session. For developers trying to claude code track agent activity, that missing visibility matters just as much as the final output.

What I actually wanted from session monitoring

I did not want a giant enterprise platform. I wanted a local, developer-friendly record of behavior. Specifically, I wanted to see tool activity as it happened, not just after the fact. I wanted a durable session log I could inspect later. And I wanted the implementation to stay close to Claude Code itself instead of requiring some fragile wrapper process that would break every time my workflow changed.

That is why agentcheck exists. It is a hooks-based behavioral governance layer for Claude Code. Instead of trying to reconstruct activity after the session from scraps, agentcheck uses Claude Code hooks to capture behavior at the point where it happens. The important hooks here are PreToolUse and PostToolUse. Those events let agentcheck record every tool invocation in real time as the agent works.

Short version: agentcheck lets me see every tool call as Claude Code runs, then writes a session summary to JSONL at the end so I can review what happened later.

How agentcheck solves Claude Code session monitoring

The design is intentionally simple. When Claude Code is running with agentcheck enabled, the hooks observe tool use before and after execution. That means I get a real-time stream of what the agent is attempting and what it completed. This is the part that makes claude code session monitoring feel concrete instead of theoretical. I can stop wondering what the agent is doing and start reading the actual event trail.

Because the monitoring is hook-driven, it follows the session naturally. There is no need to manually annotate prompts or remember to enable some extra logging mode after the fact. If the agent uses a file read tool, I can see that. If it runs a shell command, I can see that. If it edits or inspects files, the monitoring log captures the event metadata around those actions. At the end of the session, agentcheck writes a structured JSONL summary locally, which gives me a durable session record suitable for review, grep, or downstream scripting.

Here is the kind of output I wanted to have available after a run:

{
  "ts":"2026-04-21T14:02:11.481Z",
  "session_id":"cc_9fd3a2",
  "event":"PreToolUse",
  "tool":"ReadFile",
  "args":{"path":"/workspace/app/routes.ts"}
}
{
  "ts":"2026-04-21T14:02:11.689Z",
  "session_id":"cc_9fd3a2",
  "event":"PostToolUse",
  "tool":"ReadFile",
  "status":"ok",
  "duration_ms":208
}
{
  "ts":"2026-04-21T14:02:18.122Z",
  "session_id":"cc_9fd3a2",
  "event":"PreToolUse",
  "tool":"Bash",
  "args":{"command":"npm test -- --runInBand","cwd":"/workspace/app"}
}
{
  "ts":"2026-04-21T14:02:25.901Z",
  "session_id":"cc_9fd3a2",
  "event":"PostToolUse",
  "tool":"Bash",
  "status":"ok",
  "duration_ms":7779
}
{
  "ts":"2026-04-21T14:02:33.017Z",
  "session_id":"cc_9fd3a2",
  "event":"PreToolUse",
  "tool":"EditFile",
  "args":{"path":"/workspace/app/routes.ts","operation":"replace"}
}
{
  "ts":"2026-04-21T14:05:09.444Z",
  "session_id":"cc_9fd3a2",
  "event":"SessionSummary",
  "tool_calls":17,
  "files_touched":4,
  "token_estimate":48291
}

That snippet is realistic because it answers the questions I actually have during and after a session. Which tools were used? In what order? With which arguments? How long did they take? How big did the session get? If you are trying to monitor Claude Code agent behavior in a way that is useful for debugging or auditing, that information is the difference between confidence and blind trust.

Installation and setup

The setup is intentionally short. Install agentcheck globally, initialize it once, and then launch Claude Code with monitoring active:

npm install -g github:paprika-org/agentcheck
agentcheck init
# opens claude code with monitoring active
claude --no-strict-mode

That flow gives you a local monitoring layer without introducing a separate hosted dependency. I like that because it keeps the behavior visible on the same machine where the agent is running. It also makes the output easy to inspect with standard tools once the session is over.

Why local monitoring is still useful

There is a temptation to assume that if something does not have a big dashboard, it is not a serious monitoring solution. I think that is backwards for this use case. Most of the time, when I ask “claude code what is my agent doing?”, I do not need a BI suite. I need the event stream and a clean local record. I need enough detail to understand behavior, verify intent, and catch surprises early.

That makes agentcheck a good fit for solo developers, small teams, and anyone experimenting with agentic workflows who wants a governance layer before they scale usage. It is also useful if you want to track repetitive patterns in agent behavior over time. A local JSONL log is not glamorous, but it is scriptable, composable, and honest. You can parse it, diff it, archive it, or feed it into your own tooling.

Limitations

There are limits, and they are worth stating clearly. Agentcheck is local monitoring. It does not provide a cloud dashboard. It does not send alerts. It is not pretending to be a complete security platform. Today, the strength is direct visibility into Claude Code tool behavior through hooks and a usable session record at the end.

For me, that is still enough to solve the immediate problem. I wanted claude code track agent activity capabilities that are practical right now, not a vague promise. Real-time hook capture plus end-of-session JSONL gets me that. It helps me understand what happened in a run, inspect the flow of work, and establish a baseline for behavioral governance around autonomous coding agents.

If you are searching for claude code session monitoring because you want to see every tool call in real time and keep a local session log, agentcheck is the missing piece I was looking for. It does not try to hide the mechanics. It exposes them. That is exactly what I want when an agent has enough autonomy to make meaningful changes in my workspace.

Want to try it or send feedback?

See the project on GitHub or email agentcheck@agentmail.to. If you have been asking how to monitor Claude Code agent behavior in a real session, I would start there.