Your openclaw.json file contains every API key, token, and credential your agent uses to operate. If that file reached a GitHub repository, this article walks through the exact steps to stop the exposure, in the right order, with copy-paste instructions for your OpenClaw agent at every stage.
Time this takes: Rotating credentials takes 10-20 minutes depending on how many services you have configured. The history rewrite is a single command your agent runs in under a minute. Total time from start to a clean repository: under an hour for most setups. Repositories with thousands of large commits may take longer during the history rewrite step.
What is in your openclaw.json and what an attacker can do with it
Your openclaw.json file is OpenClaw’s central configuration file. It contains everything your agent needs to operate: API keys for Anthropic, OpenAI, DeepSeek, or whichever model providers you use; plugin secrets and webhook tokens; Telegram or Discord bot credentials; Cloudflare tokens; and any other integration credentials you have configured. An attacker with any one of them can impersonate you, run up charges on your API accounts, or access systems your agent is connected to.
When a file containing credentials reaches a public GitHub repository, automated bots that scan for exposed secrets typically find it within minutes. GitHub itself operates a secret scanning program (active since 2023) in partnership with major API providers including Anthropic and OpenAI. When GitHub detects a known secret pattern, it notifies the provider, and the provider may auto-revoke the key. Do not rely on this. Auto-revocation is not guaranteed, does not cover all credential types, and the revocation notice goes to the provider, not to you. Rotate everything yourself.
Step 1: Rotate every credential right now
Credential rotation means generating a new API key and revoking the old one at the source. Your OpenClaw agent can enumerate everything that needs rotating. This is the first thing you do: before making the repo private, before touching git history. Stopping live exposure is the priority.
Copy and paste this into your OpenClaw:
Read my openclaw.json file and list every API key, token, webhook secret, and credential it contains. For each one, tell me: what service it belongs to, what the key format looks like (first 4 and last 4 characters only, mask the rest), and what URL I need to visit to rotate it. Do not display any full credential values.
Your agent will return a list of every credential that needs rotating. Work through them one at a time. For each service, the sequence is: generate the new key at the provider first, add it to your config, verify your agent is working, then revoke the old key. Add and verify before you revoke. If you revoke first and something goes wrong, you may lose access to your agent temporarily and need to re-add the credential by hand.
To update a credential in your config without opening any files yourself, paste this for each service:
Update the [service name] API key in my openclaw.json to [your new key here]. Confirm the change is saved and restart the gateway if needed.
~/.openclaw/openclaw.json on Linux and Mac, or C:\Users\[your username]\.openclaw\openclaw.json on Windows. Open it in any text editor, find each key value, replace it with your new credential, save the file, and restart OpenClaw.
Step 2: Make the repository private and assess the exposure window
Once credentials are rotated, stop any further indexing of the file. A private repository is only accessible to people you explicitly invite. It cannot be indexed by search engines, scraped by automated scanners, or viewed by anyone without a GitHub account you have granted access to. If the repo is public, make it private before you touch the git history. A private repo cannot be indexed by external scanners while you work on the cleanup.
Make the repository private. Once private, only people you explicitly invite can see it. No search engines, no automated scanners, no one without a GitHub account you have granted access.
Walk me through making my GitHub repository private right now. Tell me the exact steps to find the visibility setting in GitHub, and tell me what to expect once I have done it.
Then paste this into your OpenClaw to understand what you are dealing with before the history rewrite:
I accidentally pushed my openclaw.json to a GitHub repository and have already rotated all credentials. I need to rewrite the git history to remove the file. Before I do: check this repository for any open pull requests or other branches that reference the file, and tell me if there are any collaborators with access to this repo I should notify before force-pushing rewritten history.
Step 3: Remove the file from git history
Deleting the file and pushing the deletion does not remove it from git history. The file is still accessible in every previous commit. Anyone who knows git can access it. Removing it from history requires rewriting the repository’s commit log.
Two tools handle this. git filter-repo is the current recommended approach as of 2026 (updated from 2024) and is maintained by the Git project. BFG Repo Cleaner is an older Java-based tool that still works as of March 2026 but is no longer receiving updates. The instructions below use git filter-repo. Paste this into your OpenClaw:
Check if git filter-repo is installed on this machine. If it is not installed, give me the installation command for my operating system. Then tell me the exact command to remove a file named openclaw.json from the entire git history of my current repository, and take a full backup of the repository first so I can restore it if something goes wrong.
Your agent will create the backup, confirm the tool is installed or help you install it, and give you the exact command. Read the command before you run it. When you are ready:
Run the git filter-repo command to remove openclaw.json from all commits in this repository’s history. After it completes, tell me what the output means and confirm that no trace of the file remains before I force-push to GitHub.
After your agent confirms the local history is clean, force-push:
Force-push the rewritten git history to GitHub origin. Tell me the exact command, confirm what it will do to any collaborators’ local copies, and tell me what I should check on GitHub afterward to verify the file is no longer accessible in any commit.
Step 4: Verify the file is gone
After the force-push, confirm the cleanup is complete before moving on. Paste this:
Verify that openclaw.json has been completely removed from this repository’s git history. Check all branches, all tags, and the reflog. If any trace of the file remains in any commit, tell me exactly where and what needs to be done to remove it.
Also go to your GitHub repository in a browser and use GitHub’s code search to search for “openclaw.json” within your repo. If the history rewrite worked, no results appear in any commit.
Step 5: Check for unauthorized use and close the loop
Find out whether the old keys were used during the exposure window. Your API provider’s usage dashboard logs every request made with your credentials, including timestamps and request counts. A spike between the push and your rotation is the most likely sign the key was used. Your own scheduled tasks and automations may also appear in the log during that window: look for requests from IP addresses you do not recognize, not just volume. Usage spikes in the period between the push and the rotation are the signal that the credentials were accessed by someone else. Paste this:
My API keys were potentially exposed in a GitHub repo. I rotated all credentials. Help me check the usage logs or dashboards for each of my API providers to see if there was any unusual activity during the period when the old keys were active. List each provider I use and where to find their usage dashboard.
If you see usage you do not recognize during that window, contact the API provider’s support team. Most providers have an abuse reporting process and can tell you what the keys were used for.
Step 6: Make sure this cannot happen again
openclaw.json has no business being in git. A .gitignore file is a list of filenames that git ignores completely: any file listed there is never staged, committed, or pushed regardless of what. Add openclaw.json to yours now so future pushes cannot include it:
Add openclaw.json to my .gitignore file. If no .gitignore exists, create one. Confirm the entry is present, explain what it does, and check if there are any other OpenClaw files that contain credentials that should also be excluded.
For a harder guardrail, set up a pre-commit hook that blocks any commit containing the file before it can be staged:
Set up a git pre-commit hook in my current repository that blocks any commit containing openclaw.json. Show me exactly what the hook will do before creating it, and confirm it is active after setup.
FAQ
GitHub sent me a secret scanning alert. Does that mean my key was already revoked?
It may have been. GitHub’s secret scanning partner program notifies API providers when it detects known patterns in public repos, and some providers auto-revoke on that notification. Do not rely on this. Generate a new key and revoke the old one yourself regardless of any auto-revocation that may have occurred. You want to confirm the revocation happened, not assume it.
I deleted the file and pushed the deletion. Why is that not enough?
Deleting a file in git creates a new commit that removes the file going forward, but every prior commit (a saved snapshot of your repository at a point in time) still contains it. Anyone who knows the commit hash where the file existed can access it directly. The history rewrite in Step 3 is what actually removes the file from all commits in the repository. Your repository’s code, folder structure, and commit messages are not affected. Only the commits that included openclaw.json are rewritten. Everything else stays exactly as it was. GitHub may serve a cached view of old commits for a short period after a force-push. If you check immediately after the push and still see the file, wait a few minutes and check again.
I made the repo private. Can people still see the old commits?
Once the repo is private, it is no longer publicly accessible. Anyone who cloned the public repo before you made it private still has the file in their local copy. The history rewrite and force-push updates the remote history for anyone who pulls after the push. It does not change what is already on someone else’s machine.
My openclaw.json does not have any obvious API keys, just config settings. Do I still need to rotate?
Run the enumeration command from Step 1 before deciding. openclaw.json often contains credentials in places that are easy to miss: plugin configurations, webhook URLs with tokens embedded, and provider blocks that look like metadata but contain auth strings. Let your agent list everything before you conclude nothing needs rotating.
If you add the new key before revoking the old one, your agent keeps working throughout the rotation. There is no downtime unless you revoke first. Your agent will not notice anything changed until you tell it to reload the config.
Do I need to notify anyone that this happened?
If you operate a commercial service on top of OpenClaw and any of the exposed credentials had access to customer data or customer accounts, check your applicable regulations and terms of service. Notification requirements vary by jurisdiction and contract. If this was a personal deployment with only your own credentials, no external notification is required, but documenting what happened and when is good practice if questions come up later.
Can I use BFG Repo Cleaner instead of git filter-repo?
Yes. BFG Repo Cleaner still works as of March 2026 and is faster on large repositories. It is no longer maintained, so it will not receive future updates, but it handles this specific use case correctly. Ask your agent: “I want to use BFG Repo Cleaner instead of git filter-repo to remove openclaw.json from my git history. Check if it is installed, install it if not, and give me the exact command.”
What if the repo has open pull requests from other contributors?
Contact those contributors before force-pushing. After the history rewrite and force-push, their local branches will have diverged from the remote and they will need to re-clone the repository from scratch. Give them a heads-up, a deadline, and confirm they have acknowledged before you run the force-push.
The complete hardening guide
Brand New Claw
The config mistakes that are not in the docs. Security hardening, context window setup, compaction tuning, and everything else you need to get a production-ready OpenClaw deployment that does not bite you two weeks in.
What is actually in your openclaw.json
An openclaw.json file contains more than just API keys. Understanding what an attacker can do with each piece helps you prioritize rotation.
- API keys (OpenAI, Anthropic, DeepSeek, etc.): Direct access to your AI provider accounts. Can be used to run models at your expense, potentially racking up large bills.
- Telegram/Discord bot tokens: Can send messages as your bot, read message history, potentially access channels your bot is in.
- GitHub personal access tokens: Can read/write repositories, potentially push malicious code to your projects.
- Cloud provider credentials (AWS, GCP, etc.): Can spin up resources at your expense, access storage, potentially compromise other services.
- Database connection strings: Direct access to your data stores.
- Plugin configuration secrets: May include credentials for third-party services integrated via plugins.
Read my openclaw.json and categorize every credential it contains. For each category, tell me what an attacker could do with it and how urgent rotation is.
Assessing the exposure window
How long was the file exposed? This determines how much damage could have been done.
Check when my openclaw.json was first committed to the repository and when it was made public. Calculate the exposure window in days. For each credential category, estimate what an attacker could have done in that time.
If the repository was public
Anyone could have accessed it. Assume the credentials were scraped by automated bots that scan GitHub for secrets. Rotation is urgent.
If the repository was private but you have collaborators
Only collaborators had access. Still assume rotation is needed, but the risk is lower unless you suspect a compromised collaborator account.
If you made it public briefly then made it private
The brief public window may have been enough for automated scrapers to capture the file. Assume it was captured and rotate accordingly.
Complete git history cleanup
Removing the file from the current commit is not enough. It remains in the git history. These commands completely remove it from history.
# Install git-filter-repo if not already installed pip install git-filter-repo # Backup your repository first cp -r your-repo your-repo-backup # Run filter-repo to remove openclaw.json from history git filter-repo --path openclaw.json --invert-paths # Force push to all branches git push origin --force --all git push origin --force --tags
Walk me through the git history cleanup for my repository. Show me the exact commands to run, with placeholders for my repository path and remote name. Warn me about any potential pitfalls.
Post-cleanup verification
After cleaning up, verify the file is truly gone from all branches and forks.
After running git filter-repo, verify that openclaw.json is gone from all branches. Check the git log for any remaining references. Also check whether any forks of the repository still contain the file.
Preventing recurrence
Once cleaned up, ensure this cannot happen again.
- Add openclaw.json to .gitignore: Ensure it is never committed again.
- Set up pre-commit hooks: Use a tool like pre-commit to block commits containing sensitive patterns.
- Use environment variables: Move credentials to environment variables or a secrets manager.
- Regular audits: Schedule quarterly scans for accidental commits of sensitive files.
Set up prevention measures for my repository. Add openclaw.json to .gitignore, configure a pre-commit hook to block sensitive files, and show me how to move credentials to environment variables.
Secrets management tools for OpenClaw operators
Beyond environment variables, several tools help manage credentials securely for agent operations.
1Password CLI / Bitwarden CLI: Store credentials in a password manager and retrieve them at startup. The agent never sees the raw credential in a file on disk.
HashiCorp Vault: For operators running multiple agents or enterprise setups, Vault provides centralized secret management with audit logging and automatic rotation.
SOPS (Secrets OPerationS): Encrypts specific values in config files so the file can be committed to git safely. Only someone with the decryption key can read the actual credentials.
Which secrets management approach is most appropriate for my specific setup? Consider my current tooling, the number of credentials I manage, and the effort to set up each option. Recommend one and show me how to get started with it.
Keep Reading:
Monitoring for unauthorized use after exposure
After rotating credentials, monitor for any unauthorized use that occurred during the exposure window.
API key monitoring
Check your provider dashboards for unusual activity during the exposure window. Look for: requests from unfamiliar IP addresses, usage spikes that do not match your normal patterns, model calls you did not make, and any billing anomalies.
Check my API provider dashboards for any unusual activity during the exposure window. Look for requests from IP addresses that are not my server, usage spikes, and model calls I did not initiate. Summarize any suspicious activity.
Bot token monitoring
If Telegram or Discord bot tokens were exposed, check message logs for messages you did not send. An attacker with a bot token can send messages as your bot, read channel history, and potentially access private channels.
Check my Telegram and Discord bot message history for any messages I did not send. Look for outbound messages during the exposure window that do not match my normal usage. Flag anything suspicious.
Cloud credential monitoring
If cloud provider credentials were exposed (AWS, GCP, DigitalOcean), check for: new instances spun up, storage access, IAM changes, and billing spikes. Cloud credentials are the highest-risk category because they can be used to spin up expensive resources quickly.
If I have any cloud provider credentials in my openclaw.json, check the provider’s activity logs for new resources, unauthorized access, or billing changes during the exposure window.
When to notify others about the exposure
Depending on what was exposed, you may need to notify third parties.
- API providers: If you suspect the keys were used by an attacker, notify the provider. They can investigate from their side and may be able to reverse unauthorized charges.
- Repository collaborators: If the repository had collaborators, inform them so they can rotate any shared credentials and check their own access logs.
- Downstream services: If the credentials gave access to other services (databases, cloud resources, third-party APIs), notify those service owners so they can audit access.
- Users or customers: If the exposed credentials gave access to any user data, you may have legal notification obligations depending on your jurisdiction.
Based on what was in my openclaw.json, who do I need to notify? Create a notification checklist with the specific party, what was exposed, and the message I should send to each.
Moving credentials to environment variables
The root cause of this type of exposure is storing credentials in a file that gets committed. Moving to environment variables prevents recurrence.
Setting up .env files
Create a .env file in your OpenClaw directory. Move credentials from openclaw.json to the .env file. Reference them in openclaw.json using environment variable syntax.
Help me migrate my openclaw.json credentials to environment variables. Create a .env file with all the credentials, update openclaw.json to reference the environment variables, and add .env to .gitignore. Show me the before and after for each credential.
Verifying the migration
After migration, verify that OpenClaw still functions correctly with the new credential source.
After migrating credentials to environment variables, restart the gateway and verify that all integrations still work: API calls, Telegram/Discord bots, and any other services. Report any that fail.
Long-term credential hygiene
Prevention is cheaper than incident response. These habits keep credentials safe.
- Quarterly credential rotation: Rotate all API keys every three months even without an incident. This limits the damage window if a future exposure occurs.
- Use scoped credentials: When possible, create API keys with the minimum permissions needed. A key that can only read, not write, limits what an attacker can do.
- Enable provider-side monitoring: Set up billing alerts and usage notifications on all API providers so you are alerted to unusual activity quickly.
- Regular .gitignore audits: Check that sensitive files remain in .gitignore, especially after repository restructuring or tool changes.
Set up a quarterly credential rotation reminder. Also audit my current API keys: are any of them over-permissioned? Can I create scoped keys with less access?
Go deeper
CVE-2026-25253: what it is, whether you’re exposed, and what to do now
The one-click RCE that hit 135,000+ OpenClaw instances in March 2026. Whether you’re affected, what attackers can do with it, and the exact patch.
Someone is hitting my OpenClaw instance from outside my network
What to do when you see unexpected external connections. Incident response in the right order, with copy-paste instructions for your agent at every stage.
My OpenClaw agent is making API calls I did not ask for
After credential exposure, unexpected API calls are the sign that a key was used. How to read your usage logs, identify anomalous calls, and confirm your rotated keys are clean.