VAREXIS-INDEX ยท Free evidence
MCP permission recovery and Claude SDK audit evidence
10 source-linked reviews of permission recovery, transcript completeness, hook boundaries and session configuration. Documentation does not establish live execution, authority, fact verification, settlement or deletion.
Catalogue additions are available free through the exact HTTP JSON links below. Enhanced natural-language discovery is not yet qualified for these records. They are outside MCP search, MCP preview and paid saved retrieval. No search qualification, executable capability or entitlement is added.
Complete exact-ID manifest · Full catalogue · Existing MCP coverage
Claude SDK parallel transcript reader completeness
Does a Claude SDK session reader prove that every parallel tool call was captured?
The Python SDK changelog for 0.2.170 documents a fix to get_session_messages and get_session_messages_from_store: earlier traversal could retain only one branch of a parallel-tool turn. The fix recovers sibling calls and results. This is a documented reader correction, not proof that a particular stored transcript is complete; it does not by itself qualify separate subagent readers.
Documentation reviewed 2026-10-31. Primary source.
Boundaries
- Refuse a complete-action-history finding until the installed reader/version, retained transcript and expected parallel call/result identities reconcile. Missing reader output alone is not evidence that the omitted action never ran.
- Buyer implementation, live runtime enforcement, settled payment, verified deletion or certification are not established.
- No expanded capabilities or licences for existing INDEX executables.
Complete record JSON · Exact free preview JSON · Source review
Claude SDK subagent parent linkage
Can a Claude SDK subagent transcript identify the parent action that spawned it?
Python SDK 0.2.140 documents recovery of parent_tool_use_id from subagent metadata. The pinned SessionMessage documentation links it to the parent Agent tool-use block, with None when metadata is unavailable. parent_agent_id identifies a spawning subagent, but None can mean either the main session or unavailable metadata. Top-level session readers return None for these fields.
Documentation reviewed 2026-10-31. Primary source.
Boundaries
- Refuse an unambiguous parent-action attribution from a null field. Retain and reconcile the subagent metadata, parent Agent call and session identifiers; linkage does not establish authorisation or successful completion.
- Buyer implementation, live runtime enforcement, settled payment, verified deletion or certification are not established.
- No expanded capabilities or licences for existing INDEX executables.
Complete record JSON · Exact free preview JSON · Source review
Claude SDK original and hook-modified tool output
Is the tool output seen by the Claude model necessarily the original tool result?
The pinned Python SDK PostToolUseHookSpecificOutput documents updatedToolOutput as a replacement before the result reaches the model. For built-in tools its shape must match the tool output schema; a mismatch is rejected and the original output is retained. The 0.1.74 changelog introduced this option beyond MCP-only output replacement.
Documentation reviewed 2026-10-31. Primary source.
Boundaries
- Refuse to equate a model-facing result with untouched tool evidence without retaining the original result, hook configuration, replacement and acceptance outcome. A configured replacement does not prove it was accepted or that the action succeeded.
- Buyer implementation, live runtime enforcement, settled payment, verified deletion or certification are not established.
- No expanded capabilities or licences for existing INDEX executables.
Complete record JSON · Exact free preview JSON · Source review
Claude SDK stored-session configuration continuity
Does resuming a Claude SessionStore transcript prove the original permission and hook configuration is still effective?
The Python SDK 0.2.137 changelog documents copying settings.json and cowork_settings.json into the temporary configuration directory on SessionStore resume to preserve apiKeyHelper authentication, user hooks, environment variables and permissions. It also records an earlier apiKeyHelper-only authentication failure. This specific fix does not attest that a buyer resumed with the same effective configuration.
Documentation reviewed 2026-10-31. Primary source.
Boundaries
- Refuse authority-continuity approval from transcript recovery alone. Compare effective settings, authentication method, hooks and permissions before and after resume; do not expose credential values or assume every older version loses every setting.
- Buyer implementation, live runtime enforcement, settled payment, verified deletion or certification are not established.
- No expanded capabilities or licences for existing INDEX executables.
Complete record JSON · Exact free preview JSON · Source review
Claude SDK concurrent hook ordering boundary
Can one Claude SDK hook reliably gate another hook registered for the same event?
The pinned Python SDK hooks documentation states that multiple matchers for the same event dispatch concurrently. Each hook should be independent; applications must not rely on one callback finishing before another starts. The changelog records this as a documentation clarification, not a new sequencing guarantee or runtime change.
Documentation reviewed 2026-10-31. Primary source.
Boundaries
- Refuse an ordering-dependent approval or sanitisation claim based solely on matcher list order. Verify the actual design and shared-state protection. Concurrent dispatch does not imply that all permission decisions are ignored or that tools always execute.
- Buyer implementation, live runtime enforcement, settled payment, verified deletion or certification are not established.
- No expanded capabilities or licences for existing INDEX executables.
Complete record JSON · Exact free preview JSON · Source review
Claude SDK explicit versus inherited MCP servers
Does passing mcp_servers alone establish the entire Claude SDK MCP server inventory?
The pinned Python SDK documents strict_mcp_config=False by default. Setting it to True limits the CLI to servers passed through mcp_servers and ignores other configurations it would otherwise load, including project, user/global and plugin-provided servers. This controls the configuration source set; it does not verify server identity, tool safety or effective permissions.
Documentation reviewed 2026-10-31. Primary source.
Boundaries
- Refuse a complete admitted-server inventory based only on mcp_servers when inherited configuration is unresolved. Check strict_mcp_config, CLI version and effective inventory; do not claim that every default installation loads every configuration source.
- Buyer implementation, live runtime enforcement, settled payment, verified deletion or certification are not established.
- No expanded capabilities or licences for existing INDEX executables.
Complete record JSON · Exact free preview JSON · Source review
Claude SDK terminal result and background idle boundary
Does a Claude query result prove background subagent control traffic has finished?
The Python SDK 0.2.160 changelog documents a query() fix for hooks, can_use_tool and SDK MCP servers: stdin stays open until the CLI reports idle through session_state_changed instead of closing too early around background subagent completion. The wait has a configurable ceiling, default ten minutes. Older CLIs without state events retain close-at-first-result behaviour.
Documentation reviewed 2026-10-31. Primary source.
Boundaries
- Refuse complete-background-execution or safe-retry conclusions from the first result or wait expiry alone. Reconcile task states, control-channel lifecycle and terminal evidence. CLI idle and successful business completion are different observations.
- Buyer implementation, live runtime enforcement, settled payment, verified deletion or certification are not established.
- No expanded capabilities or licences for existing INDEX executables.
Complete record JSON · Exact free preview JSON · Source review
MCP refresh versus additional authority
Can refreshing an MCP access token authorise scopes that were never granted?
RFC 6749 section 6 prohibits a refresh request from including scopes not originally granted by the resource owner. MCP 2026-07-28 describes increased-scope reauthorisation after insufficient_scope, rather than treating token renewal as new authority. A refreshed token can renew existing access; possession or successful refresh alone does not establish a grant for newly challenged scopes.
Documentation reviewed 2026-10-31. Primary source.
Boundaries
- Refuse additional-authority approval from refresh success alone. Distinguish expiry from insufficient scope, verify the existing grant and perform the applicable reauthorisation flow or stop. A fresh interactive consent prompt is not guaranteed for every provider.
- Buyer implementation, live runtime enforcement, settled payment, verified deletion or certification are not established.
- No expanded capabilities or licences for existing INDEX executables.
Complete record JSON · Exact free preview JSON · Source review
MCP reauthorisation scope accumulation
Should an MCP client request only the newest challenged scope during reauthorisation?
MCP 2026-07-28 describes computing the union of the client's previously requested scope set and the current challenge before reauthorisation. It also recommends including challenged scopes alongside previously granted ones to avoid losing permissions for other operations. This is request-set continuity, not evidence that the authorisation server granted the union.
Documentation reviewed 2026-10-31. Primary source.
Boundaries
- Refuse to treat a scope request as effective authority. Preserve the relevant resource and authorisation context, reconcile requested versus granted scopes, and do not carry unrelated credentials or authority across issuers.
- Buyer implementation, live runtime enforcement, settled payment, verified deletion or certification are not established.
- No expanded capabilities or licences for existing INDEX executables.
Complete record JSON · Exact free preview JSON · Source review
MCP repeated scope-challenge retry boundary
How long should an MCP client keep retrying after repeated insufficient_scope challenges?
MCP 2026-07-28 describes retrying the original request with new authorisation only a few times before treating it as a permanent authorisation failure. It recommends retry limits and tracking scope-upgrade attempts for the same resource and operation. The specification does not supply one universal numeric retry count.
Documentation reviewed 2026-10-31. Primary source.
Boundaries
- Refuse unbounded reauthorisation loops or automatic widening of authority to make a request pass. Set and record a bounded policy, stop on exhaustion and retain sanitised failure evidence. This limit does not establish idempotency or prove a prior business action did not execute.
- Buyer implementation, live runtime enforcement, settled payment, verified deletion or certification are not established.
- No expanded capabilities or licences for existing INDEX executables.
Complete record JSON · Exact free preview JSON · Source review