How can MCP tool calls using OAuth stay protected from storing sensitive credentials in raw-outputs jsonl?

[djacobsmeyer]

Summary

The hook system captures complete tool responses to History/raw-outputs/*.jsonl files. When MCP tools return sensitive data (OAuth credentials, API keys, PII, database passwords), these secrets:

1. Persist on disk in user-readable files
2. Are naturally read by Claude Code during debugging workflows
3. Get exposed to the AI provider when users ask Claude to analyze sessions

The primary risk is not git commits (GitHub scanning catches those) - it's that files containing secrets exist in a location where Claude Code's Read tool naturally accesses them during normal operation.

Attack Vector

Scenario:

1. User integrates MCP server (google-calendar, stripe, database, etc.)
2. MCP tool response contains credentials/secrets
3. Hook captures full response to raw-outputs/YYYY-MM-DD_all-events.jsonl
4. User encounters hook issue or wants to debug session
5. User asks: "Can you check my hook logs?"
6. Claude uses Read/Grep tools on raw-outputs directory
7. Secrets are transmitted to Anthropic servers
8. Now in AI provider's logs/training data

This is not hypothetical - it occurred in my own workflow today. (I ended up removing the MCP and writing a library based script, but that may not always be possible)

Affected MCP Integrations

Any MCP tool returning sensitive data:

• google-calendar: OAuth credentials (client_id, client_secret, tokens)
• stripe: API keys, customer PII
• postgres/mysql: Connection strings, passwords
• slack/discord: Access tokens, private messages
• s3/drive: File contents potentially containing secrets
• Any custom MCP: Depends on what data it returns

Current "Protections" (Insufficient)

What works:

• ✅ GitHub secret scanning blocks commits
• ✅ Files can be gitignored (manual setup)

What doesn't protect:

• ❌ Claude Code naturally reads these files during debugging
• ❌ No warning when Read tool accesses raw-outputs
• ❌ No automatic redaction of sensitive patterns
• ❌ Users don't know these files contain secrets
• ❌ Session summaries reference raw-outputs, encouraging inspection

Impact Analysis

Severity: Medium-High (secrets exposed to AI provider during normal operation)

Exposure paths:

1. User asks Claude to debug hooks → Claude reads raw-outputs
2. User asks Claude to analyze session → Claude reads raw-outputs
3. User shares session ID for help → Helper reads raw-outputs
4. Automated analysis tools → Read raw-outputs

Persistence: Until user manually deletes files (most won't know to)

Questions for Discussion

1. Is complete tool response capture essential for hooks? Could hooks receive sanitized/summarized data instead?

2. Should Claude Code warn before reading raw-outputs? Similar to how it confirms before running dangerous commands?

3. Should raw-outputs be ephemeral by default? Auto-delete after session ends or after summary generation?

4. Should there be automatic redaction? Pattern-match and redact known sensitive fields before writing?

5. Is this a documentation gap or design issue? Should the hook system explicitly handle sensitive data differently?

Potential Solutions (Discussion Starters)

A. Sanitize at capture time

// In capture-all-events.ts
function sanitizeToolResponse(response: any): any {
  const SENSITIVE_PATTERNS = [
    'client_secret', 'client_id', 'access_token',
    'refresh_token', 'api_key', 'password',
    'connection_string', 'private_key'
  ];
  // Recursively redact matching keys
}

B. Ephemeral by default
// Auto-delete in capture-session-summary.ts after summary generation
// Raw outputs serve only for real-time observability, not historical analysis

C. Read tool protection
// Warn when Read/Grep targets raw-outputs
if (filePath.includes('raw-outputs')) {
  console.warn('⚠️  Warning: This file may contain sensitive data from tool responses');
}

D. Separate sensitive from non-sensitive
// Two output streams:
// - raw-outputs-safe/ (tool names, timing, basic metadata)
// - raw-outputs-sensitive/ (full responses, auto-deleted)

Current Workaround

# Immediate mitigation
echo "History/Raw-Outputs/" >> .gitignore
rm -rf .claude/History/Raw-Outputs/

# Long-term: Don't ask Claude to read these files
# But this limits debugging capability

Impact on Existing Users

- Users with MCP integrations likely have credentials in raw-outputs now
- They may not realize these files exist or contain secrets
- Standard "help me debug" requests could expose credentials
- Session summaries actively point users to raw-outputs directory

Request

Looking for guidance on:
1. Whether this is considered expected behavior or needs addressing
2. What level of sanitization is acceptable without breaking debugging workflows
3. Whether there's consensus on making raw-outputs ephemeral by default
4. If this warrants a security advisory to existing users

Not rushing to PR - want to understand the appropriate design first.