Tool sessions

A tool session groups the MCP calls of one client conversation — one Claude Desktop chat, one Claude Code run, one Cursor task. Sessions give you a live view of what an agent is doing right now, and a unit that policies can reason about.

How sessions are identified

Most MCP clients send a session identifier with each request (Claude Code, Cursor, and others do this natively); Wicket uses it to correlate calls. For clients that don’t, Wicket derives a stable per-conversation fingerprint instead — sessions never mix across members or keys.

A session records:

• Client — which MCP client initiated it (from the MCP initialize handshake)
• Tools used — per-tool call counts, e.g. github:get_file_contents → 4
• Policy hits — how many times each policy matched, split into allow and deny buckets
• Timing — created, last activity, and termination (sessions expire after 30 minutes of inactivity)

Example — a session as the API returns it:

{
  "id": "ts_8814…",
  "agentType": "claude-code",
  "externalSessionId": "9d2f…",
  "isActive": true,
  "createdAt": "2026-06-12T14:00:02.000Z",
  "lastActivityAt": "2026-06-12T14:09:47.000Z",
  "toolsUsed": {
    "github:get_file_contents": 4,
    "github:create_pull_request": 1
  },
  "policiesAllowCounts": { "business-hours-github-writes": 1 },
  "policiesDenyCounts": { "block-github-destructive-tools": 2 }
}

Two denials already on the books — one more and the circuit breaker below trips. A terminated session additionally carries terminatedAt and terminatedReason (inactivity, manual_reset, or proxy_restart).

Inspect sessions

• Owners: the agent’s Sessions view lists all members’ sessions with live activity.
• Members: your member panel shows your own sessions.

Open a session to see its activity feed — the tools it called and the policies it tripped — which reads like a real-time narrative of the conversation’s actions.

Reset a session

Reset terminates a session immediately. The MCP client keeps working — the next call simply starts a fresh session with zeroed counters.

Reset matters because of session conditions: if a circuit-breaker policy has locked a session down (see below), reset is the explicit human acknowledgment that un-trips it.

Session-aware policies

Session conditions let policies depend on session history:

Circuit breaker — stop an agent that keeps hitting denials:

Field	Value
Effect	Forbid
Tools	all tools
Session condition	kind: policy, your guard policy’s key, bucket deny, operator gte, count 3

After three denied attempts in one session, everything is forbidden until a human resets the session.

Read-before-write — allow file edits only after the agent has actually read files:

Field	Value
Effect	Permit
Tools	create_or_update_file
Session condition	kind: tool, service github, tool get_file_contents, min count 1

Tip

Pair session policies with the Audit tab: matched session-condition policies appear like any other policy match, so the moment a circuit breaker trips is visible in the log — including your deny message telling the member what to do next.

Related

• Structured policy schema — session condition fields
• Trust model — who can see and reset whose sessions