Before You Paste That Log: A Safer Debugging Habit

Debugging is collaborative.

You paste a stack trace into an issue. You send curl -v output to a teammate. You drop a failing docker compose log into Discord. You ask an AI chat why a service is returning 401.

Most of the time, that is exactly how a problem gets solved quickly.

But there is a small failure mode in this workflow: the useful error and the sensitive value often live on the same line.

A log can contain a bearer token. A connection string can contain a database password. A command copied from a terminal can include a private hostname, an email address, a local username, or a callback URL with a token embedded in it.

The problem is not that developers do not care about security. The problem is that debugging creates urgency. When production is broken, nobody wants to manually inspect 400 lines of output before asking for help.

The risky part is usually not the whole line

A common reaction is to remove every line that looks remotely sensitive.

That is safer than sharing a password, but it can make the log much less useful.

Consider this connection string:

DATABASE_URL=postgresql://app_user:[email protected]:5432/orders

Deleting the whole line hides the useful parts:

• the database type
• the application user
• the host
• the port
• the database name

A better result is:

DATABASE_URL=postgresql://app_user:[REDACTED]@db.internal:5432/orders

The password is gone, but the details that help someone diagnose the failure remain.

The same idea applies to headers and URLs:

Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
callback=https://example.com/callback?token=fake-url-token&safe=1

A safer version can keep the protocol and surrounding structure:

Authorization: Bearer [REDACTED]
callback=https://example.com/callback?token=[REDACTED]&safe=1

This is the goal: remove the risky value, not the debugging context.

A practical pre-share checklist

Before posting logs or terminal output somewhere outside your machine, check for a few categories that are easy to overlook:

1. Credentials
   
   Passwords, API keys, access tokens, JWT-like values, client secrets, cookies, webhook URLs, and connection-string credentials.

2. Authorization headers
   
   Authorization: Bearer ... and Authorization: Basic ... are common in verbose HTTP output.

3. Sensitive values hidden in URLs
   
   Query parameters such as token, key, secret, signature, or access_token can end up in callbacks, debug requests, and application logs.

4. Personal or infrastructure details
   
   Email addresses, local usernames, private IP addresses, MAC addresses, internal hostnames, and local filesystem paths can expose more than the visible error suggests.

5. Command-line arguments
   
   Debug commands often contain --token, --password, --api-key, or --client-secret values.

For a short output, manual review is fine. For a large log, repeated support work, or a rushed incident, it is easy to miss something.

The workflow I wanted

I wanted a small local step that fits naturally between “I have the log” and “I am about to paste it.”

That workflow should:

• run locally, next to the data being cleaned
• preserve normal log structure
• replace only the risky substring where possible
• avoid sending the log to a third-party service
• produce a report that does not repeat the detected secret
• work with files and shell pipelines

That is why I built ShareClean, a local-first Python CLI for sanitizing developer output before sharing it.

Disclosure: I built and maintain ShareClean.

It is not a repository secret scanner and it is not a replacement for tools such as GitHub Secret Scanning, Gitleaks, TruffleHog, or DLP systems. Those tools solve different problems: scanning source code, commit history, repositories, or managed environments.

ShareClean is for the earlier and smaller moment: the text that has not been shared yet.

Using it in a normal debugging flow

Install it with:

pipx install shareclean

Clean a log and print the result:

shareclean app.log

Write a cleaned copy without touching the original:

shareclean app.log --output app.cleaned.log

Or pipe output directly from another command:

cat app.log | shareclean

For a safe, metadata-only summary of what was replaced:

shareclean app.log --report

The report is designed not to include matched values, source snippets, filenames, paths, hashes, or masked previews. The point is to confirm what happened without creating a second place where the secret appears.

It can also be used as a guard in CI or a pre-share workflow:

shareclean app.log --check
shareclean app.log --check --fail-on severity:high

The project supports options for common categories such as private IPs, phone numbers, MAC addresses, custom patterns, and project-level configuration.

What this does not solve

No pattern-based tool can guarantee that every secret format will be detected.

Unusual proprietary credentials, values with unexpected formatting, encoded content, and context-specific identifiers can be missed. A tool can also redact harmless text that resembles a secret.

That is why this should be treated as a practical safety layer, not a promise of perfect sanitization.

The useful feedback is not “does it catch every possible secret?” Nothing realistically does.

The useful feedback is:

• What did it miss in a realistic fake log?
• What did it redact too aggressively?
• Which output formats do you regularly need to share?
• Did it preserve enough context for another developer to help?

Every fake failure case can become a regression test.

Try it with fake data

The repository, installation instructions, and supported rules are available here:

• GitHub: https://github.com/OmarH-creator/ShareClean
• Browser playground for fake/sample text: https://omarh-creator.github.io/ShareClean/

The playground is for experimenting with fake text in the browser. For real logs and configuration output, the intended workflow is the local CLI.

I would particularly welcome examples from DevOps and backend work: Docker logs, reverse-proxy output, verbose HTTP traces, Kubernetes events, Compose environment variables, CI logs, database connection errors, and stack traces where the balance between privacy and useful context is hard to get right.