Thanks for this great plugin. I've used this extensively in my personal workflow and planning to suggest using it in my new workplace.
One of the concerns I have is lack of secret pruning. Better strategy is restricting claude to not to read secrets but hey ho things oppsies happen :) Maybe you guys have a filtering at your backend and I wanted to check how does it work.
here's claude communicating the issue better than me:
Problem
The trace-claude-code hooks currently send all tool inputs and outputs to Braintrust without any filtering. This means sensitive data like API keys, passwords, and tokens are uploaded to the cloud if Claude reads files containing them.
Example scenario:
User asks Claude to "check my .env file"
PostToolUse hook captures the file content including DATABASE_URL=postgres://user:password@host/db
This gets sent directly to api.braintrust.dev/v1/project_logs/.../insert
Proposed Solution
Add a configurable redaction layer before sending data. Key features:
- Pattern-based redaction (in
common.sh
):
Common API key patterns: sk-, ghp_, xoxb-, AKIA
Generic secrets: password=, secret=, api_key=, token=
2. File-type blocklist:
Skip content logging for: *.env, *.pem, *.key, credentials, secret
Log metadata only: {"file": ".env", "content": "[REDACTED - SENSITIVE FILE]"}
3. User configuration via environment variables:
json
{
"env": {
"BRAINTRUST_REDACT_PATTERNS": "sk-.,ghp_.,custom_pattern.",
"BRAINTRUST_SKIP_FILES": ".env,*.pem",
"BRAINTRUST_REDACT_ENABLED": "true"
}
}
Files to modify
skills/trace-claude-code/hooks/common.sh
— add redact_secrets() function
skills/trace-claude-code/hooks/post_tool_use.sh
— apply redaction to TOOL_INPUT and TOOL_OUTPUT
skills/trace-claude-code/hooks/stop_hook.sh
— apply redaction to conversation content
skills/trace-claude-code/SKILL.md
— document the new options
Security impact
This is a significant security improvement for users who:
Work with production credentials
Have .env files in their projects
Use Claude to debug authentication issues
Without this, users must choose between observability and security — they shouldn't have to.
Thanks for this great plugin. I've used this extensively in my personal workflow and planning to suggest using it in my new workplace.
One of the concerns I have is lack of secret pruning. Better strategy is restricting claude to not to read secrets but hey ho things oppsies happen :) Maybe you guys have a filtering at your backend and I wanted to check how does it work.
here's claude communicating the issue better than me:
Problem
The trace-claude-code hooks currently send all tool inputs and outputs to Braintrust without any filtering. This means sensitive data like API keys, passwords, and tokens are uploaded to the cloud if Claude reads files containing them.
Example scenario:
User asks Claude to "check my .env file"
PostToolUse hook captures the file content including DATABASE_URL=postgres://user:password@host/db
This gets sent directly to api.braintrust.dev/v1/project_logs/.../insert
Proposed Solution
Add a configurable redaction layer before sending data. Key features:
common.sh
):
Common API key patterns: sk-, ghp_, xoxb-, AKIA
Generic secrets: password=, secret=, api_key=, token=
2. File-type blocklist:
Skip content logging for: *.env, *.pem, *.key, credentials, secret
Log metadata only: {"file": ".env", "content": "[REDACTED - SENSITIVE FILE]"}
3. User configuration via environment variables:
json
{
"env": {
"BRAINTRUST_REDACT_PATTERNS": "sk-.,ghp_.,custom_pattern.",
"BRAINTRUST_SKIP_FILES": ".env,*.pem",
"BRAINTRUST_REDACT_ENABLED": "true"
}
}
Files to modify
skills/trace-claude-code/hooks/common.sh
— add redact_secrets() function
skills/trace-claude-code/hooks/post_tool_use.sh
— apply redaction to TOOL_INPUT and TOOL_OUTPUT
skills/trace-claude-code/hooks/stop_hook.sh
— apply redaction to conversation content
skills/trace-claude-code/SKILL.md
— document the new options
Security impact
This is a significant security improvement for users who:
Work with production credentials
Have .env files in their projects
Use Claude to debug authentication issues
Without this, users must choose between observability and security — they shouldn't have to.