feat: add MCP redaction filtering for sensitive data

[silasjmatson]

Warning: This was vibe-coded, we'll want to verify the architecture is what we want and review thoroughly.

Description

Add a secure-by-default redaction system that filters sensitive data from all MCP resource and tool responses. Uses a two-key model where default rules apply automatically and disabling requires agreement from both the client app and the Reactotron desktop app.

Redaction engine:

• Key matching: redacts object keys matching sensitiveKeys (case-insensitive)
• Header matching: redacts HTTP headers matching headerNames
• Value patterns: regex-based detection of Bearer tokens, JWTs, API keys
• State path patterns: dot-separated paths with wildcard support
• URL query params: redacts query param values matching sensitiveKeys
• Handles circular references, nested objects, and arrays

Client apps can send additionalRules (always allowed) or removeRules/ disableRedaction (requires server permission via settings modal).

Desktop app: settings modal for editing rules and client permissions, redaction status indicator (shield icon) in footer, config persisted via electron-store.

44 tests (30 unit + 14 integration). Docs updated.

Please verify the following:

• yarn build-and-test:local passes
• I have added tests for any new features, if relevant
• README.md (or relevant documentation) has been updated with your changes

[joshuayoes]

🐛 Redaction gap: request bodies aren't redacted by key

What I saw (manual QA on iOS sim + Android emulator):

Fired an API call with:

fetch("https://jsonplaceholder.typicode.com/posts?api_key=X&page=2", {
  method: "POST",
  headers: { Authorization: "Bearer abc...", Cookie: "session=..." },
  body: JSON.stringify({ password: "hunter2", api_key: "x", accessToken: "y",
                         note: "embedded sk-ABCDEFGHIJKLMNOPQRSTUVWX" }),
})

Reading reactotron://timeline/api.response via MCP, the response body is fully redacted, but the request body leaks:

"request": {
  "data": "{\"password\":\"hunter2\",\"api_key\":\"x\",\"accessToken\":\"y\",\"note\":\"embedded [REDACTED] ...\"}",
  "headers": { "authorization": "[REDACTED]", "cookie": "[REDACTED]" },
  "params": { "api_key": "[REDACTED]", "page": "2" }
}

Headers, URL query params, and the sk- token inside note (via valuePatterns) are redacted correctly. But password, api_key, accessToken in the body string pass through.

Root cause: fetch({ body: JSON.stringify(...) }) gives the networking plugin a string, cached verbatim as tronRequest.data (lib/reactotron-react-native/src/plugins/networking.ts:92-96). The redactor walks object keys but only applies valuePatterns to strings (lib/reactotron-mcp/src/redaction.ts:219-239), so the JSON-shaped string is never parsed and key-level redaction never runs on the body.

Who's affected: anyone using fetch / axios / apisauce with a JSON body — auth endpoints ({ password }), token refresh, payment flows, etc. will leak to the MCP client.

Suggested fix: in redactStringValue or summarizeNetworkEntry, detect strings that look like JSON (start with { or [, or Content-Type application/json), JSON.parse → redact → JSON.stringify, fall back to valuePatterns if parsing throws.

[joshuayoes]

🐛 State path patterns silently fail when requesting a subtree

Repro:

1. Added a Redux slice so state.redactionTest.auth.tokens = { access: "...", refresh: "..." }.
2. In the MCP redaction settings modal, added redactionTest.auth.tokens.* to State Path Patterns.
3. Via MCP: request_state({ path: "redactionTest.auth" }).

Actual:

{ "username": "alice", "password": "[REDACTED]", "api_key": "[REDACTED]",
  "tokens": { "access": "access-raw-value", "refresh": "refresh-raw-value" } }

tokens.access / tokens.refresh pass through despite the pattern.

Expected: both redacted. Confirmed the pattern matcher itself works — changing the pattern to tokens.* (relative to the returned subtree) does redact correctly.

Root cause: lib/reactotron-mcp/src/tools.ts:162 calls applyRedaction(stateValue, ...) with the path-scoped subtree, and redact() defaults currentPath = "" (lib/reactotron-mcp/src/redaction.ts:109). So tokens.access is walked with currentPath = "tokens.access" — the user-written absolute pattern redactionTest.auth.tokens.* has no chance of matching.

Why it matters: the settings-modal UI encourages absolute paths (the placeholder example is auth.tokens.*, suggesting patterns anchored to the state root). But those patterns silently no-op as soon as a caller uses a path-scoped request — and LLMs are strongly encouraged to do so by the request_state tool description ("Always specify a path to avoid oversized responses"). State path patterns effectively only work when reading reactotron://state/current (which returns the whole tree).

Suggested fix: thread the requested path through applyRedaction to redact() as the initial currentPath:

// tools.ts
const redactedState = applyRedaction(stateValue, server, serverRedactionConfig, clientId, args.path ?? "")

// redaction.ts
export function applyRedaction(data, server, config, clientId, basePath = "")
// -> return redact(data, rules, basePath)

Same treatment for any other path-scoped code paths that return subtrees.

[joshuayoes]

ℹ️ State path patterns have limited effective surface

Related to the state-path-pattern bug above: in the example app, request_state({ path: "" }) returns only { repo, logo } even though request_state_keys({ path: "" }) correctly reports ["logo", "repo", "error", "redactionTest"]. The error and redactionTest slices initialize with empty or nested-empty payloads and don't appear in the root state snapshot that reactotron-redux pushes.

Combined with the subtree bug, this means state-path patterns written as absolute paths only fire in a narrow window: the reactotron://state/current resource, and only for slices that reactotron-redux bothers to serialize at the root. Worth double-checking whether this is a reactotron-redux serialization quirk or something else — either way, state-path patterns as-designed are more of a last-resort filter than a primary line of defense.

Not blocking this PR — flagging for context.

[joshuayoes]

⚠️ Low severity — AsyncStorage mutations leak when keys/values carry secrets

Caveat up front: AsyncStorage isn't encrypted storage, and no one should be stashing secrets there. But in practice people do — tokens, session blobs, cached auth headers — and the MCP server exposes these mutations verbatim via reactotron://asyncstorage, so it's worth pointing out what does and doesn't redact.

Repro:

AsyncStorage.multiSet([
  ["auth:password", "hunter2"],
  ["auth:api_key", "leaked-api-key"],
  ["auth:accessToken", "leaked-access-token"],
  ["auth:session", JSON.stringify({ password: "hunter2", api_key: "leaked",
                                   note: "Bearer abcdef1234567890ABCDEFGH" })],
])

Actual (via reactotron://asyncstorage):

{
  "pairs": [
    { "0": "auth:password",    "1": "hunter2" },
    { "0": "auth:api_key",     "1": "leaked-api-key" },
    { "0": "auth:accessToken", "1": "leaked-access-token" },
    { "0": "auth:session",     "1": "{\"password\":\"hunter2\",\"api_key\":\"leaked\",\"note\":\"[REDACTED]\"}" }
  ]
}

Only the Bearer value pattern inside the auth:session JSON string got caught. The bare key names (auth:password), the bare values (hunter2), and the password/api_key fields inside the JSON string body all pass through.

Why: the multiSet payload shape is { pairs: [{0: "auth:password", 1: "hunter2"}] }. The redactor walks object keys — pairs, 0, 1 — none of which match sensitive keys. String values are only tested against valuePatterns, and none of the default regexes match bare secrets or namespaced storage keys. Same root issue as the JSON-body gap for network requests.

Pragmatic suggestion:

• In whatever shapes AsyncStorage mutations (summarizeCommand for asyncStorage.mutation), when serializing key / value pairs, split the key on common separators (. : _ /) and test each segment against sensitiveKeys — if any match, redact the value.
• Reuse whatever JSON-string-aware fix ends up landing for the request-body gap here too — a value like {"password":"..."} should get parsed → redacted → re-stringified.

Not security-critical on its own (AsyncStorage isn't encrypted to begin with), but it's the third place where "string values carrying structured data" sidestep the redactor, so the fix probably lands once and covers all three.