DEV Community: Kazim Ali

Millions of Developers Are Feeding Their API Keys to AI — Are You One of Them?

Kazim Ali — Sun, 08 Mar 2026 11:27:43 +0000

You open a project in VS Code. Claude Code is active in the terminal. You click on a line in your .env file — maybe to copy a value, maybe just to check something. You highlight the line:

STRIPE_SECRET_KEY=sk_live_4xKj2...

That key is now in the AI's context window. It will be sent to Anthropic's servers on the next request. No warning appeared. No prompt asked for confirmation. It just happened.

This is not a theoretical vulnerability. It is the default behaviour of every AI coding assistant with file access — Claude Code, GitHub Copilot, Cursor, Codeium. The tools that make you faster are also the tools that can silently exfiltrate your production credentials.

The Three Attack Surfaces

1. File Reads

AI coding assistants operate inside your project directory. They are designed to read files to understand context — your codebase, your config, your dependencies. The problem is that the same directory where your source code lives is also where your secrets live.

Files that are routinely read and sent to AI APIs:

.env
.env.local
.env.production
service_account.json
credentials.json
*.pem
*.key
~/.ssh/id_rsa (if project is in home directory)

Claude Code, by default, will read any file you ask it to look at. If you ask it to "fix the database connection issue" and your database URL is in .env, a capable assistant will read .env to understand the connection string. Your credentials leave your machine.

.gitignore does not help here. .gitignore tells git what not to track. It says nothing to your AI assistant.

2. IDE Selection

This is the surface most developers don't think about. When you highlight text in your editor while an AI assistant has focus, that selected text becomes context. This is a feature — it's how you tell the AI "look at this specific code." It's also how you accidentally hand over a secret.

Common scenarios:

You're debugging. You highlight an error trace that includes an auth token in the request headers.
You're checking a config file. You select the wrong line.
You paste a curl command with -H "Authorization: Bearer sk_live_..." into the chat to ask why the request is failing.

There is no mechanical block for this surface. If text is in your editor and you select it, it can reach the AI.

3. Paste and Conversation

Developers routinely paste error messages into AI chat. Error messages are often more revealing than the code itself.

A Django 500 error might include:

django.db.utils.OperationalError: could not connect to server
  Connection string: postgres://admin:mypassword123@prod-db.us-east-1.rds.amazonaws.com/orders

A failed AWS SDK call might include your region, account ID, and role ARN. A Stripe webhook error might echo back the signing secret. You're asking the AI to help you fix the error — you paste the full trace — the secret is now in the conversation history, which is stored server-side.

Why This Is Different from a Git Leak

When a secret ends up in a git commit, the exposure is to whoever has access to the repository — usually your team, maybe the public if the repo is open. Bad, but bounded.

When a secret ends up in an AI context window, it is transmitted to a third-party API endpoint over HTTPS, processed by a model running on external infrastructure, potentially stored in conversation logs, and potentially used for model training depending on your plan and the provider's data retention policy.

Every major AI provider has a data use policy. Most enterprise plans have stronger protections. Most individual developer plans do not. If you are using a free tier or a standard subscription, assume your prompts are retained.

A git leak is a repository problem. An AI context leak is a network problem. It's the difference between leaving a key under your doormat and mailing a copy to a stranger.

The Fix

Defense operates on two layers: mechanical and instructional. You need both.

Mechanical Layer: Deny Rules in settings.json

Claude Code reads its permissions from .claude/settings.json at the project root. The permissions.deny block tells it which files it is not allowed to read, regardless of what you or the AI asks.

{
  "permissions": {
    "deny": [
      "Read(.env)",
      "Read(.env.*)",
      "Read(service_account.json)",
      "Read(credentials.json)",
      "Read(**/*.pem)",
      "Read(**/*.key)",
      "Read(**/*.p12)",
      "Read(**/*.pfx)",
      "Read(**/secrets/**)"
    ]
  }
}

This file should be committed to the repository. It protects everyone on the team, not just you.

.claudeignore at Project Root

Claude Code respects a .claudeignore file using the same syntax as .gitignore. This prevents the AI from indexing or referencing those paths during context building:

.env
.env.*
service_account.json
credentials.json
*.pem
*.key
*.p12
secrets/

This is your second line of defence. If a deny rule is misconfigured, .claudeignore may catch what slips through.

Instructional Layer: Global CLAUDE.md

Create or edit ~/.claude/CLAUDE.md — this file contains global instructions that apply to every Claude Code session, across all projects. Add this:

## Security

If you detect an API key, secret, token, password, private key, or credential
in any file you have read or any text that has been shared with you, stop
immediately and warn the user before proceeding. Do not include credential
values in any response, code block, or suggestion. Ask the user to remove
the credential from context and rotate it.

Never read .env, .env.*, service_account.json, credentials.json, *.pem,
or *.key files unless the user has explicitly confirmed they understand
the credential will be transmitted to an external API.

This does not replace the deny rules. Instructions can be overridden by future prompts. Mechanical deny rules cannot.

The IDE Selection Gap

The deny rules and .claudeignore file protect against automated file reads. They do nothing when you manually select text and paste it into the chat.

This gap cannot be closed mechanically. No setting stops you from highlighting your .env file and asking "why is this connection string wrong?"

The only defence is awareness:

Before pasting an error trace, scan it for tokens, passwords, or connection strings.
Before selecting a block of config, check what's in the selection.
If you need the AI to help with a connection issue, replace the credential in the error message with a placeholder before pasting.

Treat the AI chat window the same way you treat a public Slack channel. Once it's in there, it's gone.

Five Things to Do Right Now

Add a permissions.deny block to .claude/settings.json in every project that has secrets. Copy the JSON block above. Commit it.
Create a .claudeignore at the project root listing .env, service_account.json, and any other credential files. Commit it.
Edit ~/.claude/CLAUDE.md to add the global security instruction block. This applies across all your projects immediately.
Rotate any key that has appeared in an AI chat session — including ones you're not sure about. If there's a chance it was in context, treat it as compromised.
Check your AI provider's data retention policy for the plan you are on. If you are on a free or individual plan with no data processing agreement, assume prompts are retained. Upgrade or adjust accordingly.

The tools are not going away. They are too useful. But "useful" and "safe by default" are not the same thing — and right now, the defaults are not in your favour. Spend ten minutes on this. The cost of a rotated key is an afternoon. The cost of a leaked production secret is significantly higher.

Want to go further? The fixes above reduce the risk of an AI reading your .env file. The deeper fix is to not have a .env file at all. Tools like direnv load secrets directly into your shell session from a vault or password manager — nothing is ever written to disk in your project directory. No file, no attack surface.

I built a Claude Code skill for ShopifyQL

Kazim Ali — Mon, 02 Mar 2026 10:47:04 +0000

If you've written ShopifyQL queries more than a handful of times, you know the drill — open the docs, check the keyword order, remember whether HAVING comes before or after ORDER BY, double-check the segment function syntax, close the tab, repeat.

I got tired of it and built a Claude Code skill that bakes all of that knowledge directly into Claude.

What it does

The skill auto-triggers whenever you ask Claude to:

Write a ShopifyQL analytics query
Build a customer segment filter
Debug a ShopifyQL error
Translate a business question into a query ("show me top products by revenue last month")

No slash commands, no setup per-session. It just kicks in.

What's covered

ShopifyQL (analytics queries)

Full syntax support including the strict keyword ordering that trips everyone up:

FROM → SHOW → WHERE → GROUP BY → SINCE/UNTIL → HAVING → ORDER BY → LIMIT → VISUALIZE

Plus: TIMESERIES, COMPARE TO, WITH modifiers (PERCENT_CHANGE, CUMULATIVE_VALUES, etc.), VISUALIZE, semi-joins, math on metrics, and TOP N.

Segment Query Language (customer segments)

All attribute types, operators, and functions:

products_purchased MATCHES (tag = 'sale', date > -90d)
storefront_event.product_viewed MATCHES (product_id = 1234567890, date > -7d)
shopify_email.opened MATCHES (activity_id = 5240029206, date > -30d)
anniversary() MATCHES (date = today, attribute = 'birthdate')
customer_within_distance() MATCHES (lat = 40.7128, lng = -74.0060, distance = 50, unit = 'km')

Common patterns built in

Things like top revenue products, channel attribution, high-value customer segments, re-engagement filters — ready to use or adapt.

Debugging checklist

The most common ShopifyQL mistakes in one place:

Keyword order wrong?
String values in double quotes instead of single?
Filtering on a metric in WHERE instead of HAVING?
Missing GROUP BY when showing a dimension?
Rate limit hit (429 → wait 60 seconds)?

Install

/plugin marketplace add devkindhq/shopifyql-skill
/plugin install shopifyql@shopifyql-skill

That's it. Restart Claude Code and it's active.

Example

Ask Claude something like:

"Show me revenue by channel for the last 30 days with a comparison to the previous period"

And it'll produce:

FROM sessions
SHOW referrer_source, sum(converted_sessions) AS conversions, sum(net_sales) AS revenue
GROUP BY referrer_source
SINCE -30d UNTIL today
COMPARE TO previous_period
ORDER BY revenue DESC

Or for a segment:

"Customers who bought in the last 90 days, spent over $500, and are subscribed to email"

amount_spent > 500 AND number_of_orders >= 1 AND last_order_date > -90d AND email_subscription_status = 'SUBSCRIBED'

GitHub

The skill is open source. PRs welcome — especially if you have common query patterns worth adding.

👉 github.com/devkindhq/shopifyql-skill

Mastering Repository Sync: Your Guide to Automated GitHub Workflows for Seamless CI/CD

Kazim Ali — Mon, 23 Jun 2025 09:09:42 +0000

Unlock Efficiency: Why Automated Repository Synchronization is Your Next DevOps Win

In today's fast-paced DevOps landscape, maintaining consistency across multiple codebases is a common challenge. Whether you're managing monorepos, distributing code to different environments, or simply ensuring a mirror of your primary project, manual repository updates are a recipe for errors, delays, and frustrating merge conflicts.

Imagine a world where your critical code branches are automatically synchronized, ensuring every linked repository is always up-to-date. This isn't a distant dream; it's a practical reality achievable with GitHub Actions. This article will guide you through creating a robust GitHub Actions workflow designed for repository synchronization, transforming your version control strategy from reactive to proactive and enabling truly automated deployments.

The Imperative of Automation: Beyond Manual Copy-Pasting

Why invest in automated repository sync? The benefits extend far beyond saving a few clicks:

Consistency is King: Eliminate discrepancies between connected repositories, ensuring every team member and deployed environment works with the exact same codebase.
Boosted Efficiency: Free up developer time from tedious manual updates, allowing them to focus on innovation and feature development.
Reduced Human Error: Manual processes are prone to mistakes. Automation eliminates these, ensuring flawless replication.
Seamless CI/CD Pipelines: A synchronized repository is a prerequisite for reliable Continuous Integration (CI) and Continuous Delivery (CD). Ensure your deployment targets always receive the correct code.
Disaster Recovery & Redundancy: Maintain up-to-date backups or mirrors effortlessly.

GitHub Actions: The Engine Behind Your Automation

At the heart of this solution lies GitHub Actions, GitHub's powerful CI/CD platform. GitHub Actions allows you to automate tasks directly within your repository, triggered by events like code pushes, pull requests, or scheduled intervals. It's a versatile tool for building, testing, and deploying your code, and in our case, for intelligent repository automation.

Crafting Your Repository Sync Workflow: A Deep Dive

Let's break down the YAML configuration for our repository synchronization workflow. This robust script leverages key GitHub Actions features to ensure secure and reliable syncing.

# GitHub Actions Workflow for Repository Synchronization

name: Repository Sync

# This workflow is triggered on pushes to a specific branch (e.g., 'main' or 'develop')
# in the source repository.
on:
  push:
    branches:
      # Define the branch in the source repository that will trigger this workflow.
      # Replace 'main' with your desired source branch (e.g., 'develop', 'release').
      - main # <<<--- Configure your source branch here

# Environment variables that can be used throughout the workflow.
# These provide configuration options for the synchronization process.
env:
  # The full authenticated URL for the destination repository.
  # This variable now directly references a GitHub Secret named DESTINATION_AUTH_REPO_URL.
  # This secret *must* contain the complete URL including the PAT
  # (e.g., [https://username:YOUR_PAT@github.com/OWNER/REPO.git](https://username:YOUR_PAT@github.com/OWNER/REPO.git)).
  DESTINATION_AUTH_REPO_URL: ${{ secrets.DESTINATION_AUTH_REPO_URL }} # <<<--- Directly referencing the secret

  # The name for the Git bot user that will make commits in the destination repository.
  # This is purely for commit authorship in the destination repo's history.
  GIT_BOT_NAME: 'GitHub Actions Bot' # <<<--- Defined at job level for wider access

  # The email for the Git bot user.
  GIT_BOT_EMAIL: 'actions@github.com' # <<<--- Defined at job level for wider access

jobs:
  sync:
    # Optional: Add a condition to restrict workflow execution to a specific repository owner.
    # This ensures the workflow only runs for repositories owned by a certain user or organization.
    # Replace 'your-repo-owner' with your actual repository owner.
    if: github.repository_owner == 'your-repo-owner' # <<<--- Configure your repository owner condition here

    runs-on: ubuntu-latest

    steps:
      - name: Checkout Source Repository
        # Uses the latest recommended actions/checkout to clone the source repository.
        # This step is essential to get the content that needs to be synchronized.
        uses: actions/checkout@v4
        with:
          # Fetches the entire history for force push operations.
          fetch-depth: 0
          # Ensure credentials are not persisted, as we're handling auth via URL for push.
          persist-credentials: false

      - name: Configure Git User
        # This step sets the Git user name and email for the bot.
        # These credentials will be used for the commits pushed to the destination repository,
        # ensuring the commit author is the bot.
        run: |
          git config user.name "${{ env.GIT_BOT_NAME }}"
          git config user.email "${{ env.GIT_BOT_EMAIL }}"

      - name: Push to Destination Repository
        # This step performs the actual synchronization by pushing the changes
        # from the source repository to the destination repository.
        run: |
          # Add a blank commit before pushing. This can be useful to trigger
          # downstream actions or simply mark a synchronization point without
          # actual content changes.
          git commit --allow-empty -m "Blank commit before sync"

          # Use the pre-configured authenticated URL from the environment variable.
          # This variable is assumed to be a secret that already contains the PAT within its value.
          git push --force "${{ env.DESTINATION_AUTH_REPO_URL }}" HEAD:main # <<<--- Using the authenticated URL from the environment variable

Deconstructing the Workflow:

Trigger (on: push: branches: - main)
- The workflow listens for push events. Specifically, it only activates when code is pushed to the main branch of your source repository. This ensures that only stable or primary branch updates initiate a sync.
Conditional Execution (if: github.repository_owner == 'your-repo-owner')
- A critical security and control measure. The entire sync job will only execute if the repository where the workflow resides is owned by the specified owner. This prevents unintended runs in forks or personal copies, safeguarding your DevOps environment. Remember to replace 'your-repo-owner' with your actual GitHub username or organization name.
Environment Variables (env)
- DESTINATION_AUTH_REPO_URL: This is your golden ticket for authentication. It directly references a GitHub Secret of the same name. This secret must contain the full Git URL for your destination repository, including the Personal Access Token (PAT) embedded for authentication (e.g., https://username:YOUR_PAT@github.com/OWNER/REPO.git). This is the most secure way to handle sensitive credentials in automated workflows.
- GIT_BOT_NAME & GIT_BOT_EMAIL: These define the identity that will be used for the commits pushed to the destination repository. This ensures that the commit history clearly reflects that the changes were made by an automation bot, not a specific user.
Checkout Source Repository Step
- uses: actions/checkout@v4: This is the standard GitHub Action to clone your repository onto the runner.
- with: fetch-depth: 0: Essential for force pushes. It ensures that the entire commit history (not just the latest commit) is fetched, allowing Git to correctly handle divergent histories.
- persist-credentials: false: Prevents the actions/checkout action from persisting default GitHub credentials, ensuring your explicit PAT in DESTINATION_AUTH_REPO_URL is used for the push.
Configure Git User Step
- git config user.name ... and git config user.email ...: These commands are executed before any Git operations that create commits. They set the local Git configuration on the runner to use the GIT_BOT_NAME and GIT_BOT_EMAIL defined in your environment variables. This correctly attributes the upcoming blank commit and subsequent pushes.
Push to Destination Repository Step
- git commit --allow-empty -m "Blank commit before sync": A clever trick! This creates a new commit that has no actual file changes. This can be incredibly useful for:
  - Triggering downstream CI/CD: Ensures that even if the source content hasn't changed, a new push event occurs in the destination repo, potentially triggering other workflows (e.g., deployments).
  - Clear Audit Trail: Provides a visible commit in the destination's history, indicating a synchronization event occurred.
- git push --force "${{ env.DESTINATION_AUTH_REPO_URL }}" HEAD:main: This is the core synchronization command.
  - --force: Use with extreme caution! This flag ensures that the main branch in your destination repository is overwritten with the exact state of the source repository's HEAD. This is crucial for mirroring but can erase history in the destination if misused.
  - "${{ env.DESTINATION_AUTH_REPO_URL }}": Authenticates the push using the PAT embedded in the secret URL.
  - HEAD:main: Pushes the current state of the source repository (HEAD) to the main branch of the destination.

Implementation Guide: Getting Started

Create Your PAT
- Go to your GitHub Settings > Developer settings > Personal access tokens > Tokens (classic).
- Generate a new token.
- Crucial Scopes: Ensure it has at least the repo scope (for general repository access) and, most importantly, the workflow scope. The workflow scope is necessary if your synchronization might create or modify workflow files in the destination repository.
- Copy the generated token immediately; you won't see it again.
Create the GitHub Secret
- In your source GitHub repository, navigate to Settings > Secrets and variables > Actions > New repository secret.
- Name the secret exactly DESTINATION_AUTH_REPO_URL.
- For the value, enter the complete authenticated URL, replacing placeholders: https://YOUR_GITHUB_USERNAME:YOUR_PAT_TOKEN@github.com/YOUR_DESTINATION_REPO_OWNER/YOUR_DESTINATION_REPO_NAME.git (Or if using newer PATs, https://x-oauth-basic:YOUR_PAT_TOKEN@github.com/YOUR_DESTINATION_REPO_OWNER/YOUR_DESTINATION_REPO_NAME.git)
Add the Workflow File
- In your source repository, create a directory structure: .github/workflows/.
- Inside this directory, create a new YAML file, e.g., sync-repo.yml.
- Paste the entire workflow code provided above into sync-repo.yml.
Customize
- Change main in the on: push: branches: section to your desired source branch.
- Verify if: github.repository_owner == 'your-repo-owner' is correct for your setup. Remember to replace 'your-repo-owner' with your actual GitHub username or organization name.
- Ensure the git push command's HEAD:main correctly targets the branch name you want to update in your destination repository.
Commit and Push
- Commit the sync-repo.yml file to your main branch.
- Pushing this commit will trigger the workflow, and you'll see your repository synchronize automatically!

Best Practices for Robust Sync Workflows

Least Privilege for PATs: Always grant your Personal Access Tokens only the minimum necessary permissions. Review and revoke them periodically.
Branch Protection Rules: On your destination repository, consider setting up branch protection rules for the synced branch (e.g., main). This can prevent accidental direct pushes and ensures that only the automated workflow (via PAT) can modify it.
Monitoring: Regularly check the "Actions" tab in your source repository to monitor workflow runs, ensuring they complete successfully. Set up notifications for failures.
Idempotency: The git push --force ensures idempotency for the synchronization—running it multiple times will have the same effect as running it once if the source hasn't changed.
Error Handling: For more advanced scenarios, consider adding steps for error notifications (e.g., sending Slack messages) if the sync fails.

Conclusion: Empower Your Development with Automated Sync

Automating repository synchronization with GitHub Actions is a game-changer for any development team striving for efficiency, consistency, and robust CI/CD pipelines. By implementing this workflow, you're not just moving files; you're building a resilient and self-managing version control system that empowers your DevOps practices and accelerates your path to automated deployments.

Embrace the power of GitHub Automation and let your code flow seamlessly across your entire development ecosystem!

Keywords: GitHub Actions, Repository Synchronization, CI/CD, Automated Deployments, DevOps, Version Control, Git workflows, Personal Access Token (PAT), Secret Management, GitHub Automation, Automated Sync, Git Push Force, Workflow Scope, YAML, Continuous Integration, Continuous Delivery