10 Dangerous Prompt Patterns in Claude Code | What Not to Say and Safe Alternatives

Are you writing prompts thinking “it’ll probably get what I mean”? Claude Code executes instructions literally. Vague or dangerous instructions produce unintended results.

This article covers 10 dangerous prompt patterns that have caused real incidents, along with safe alternatives for each. If you recognize any of these patterns after reading, change them immediately.

---

Pattern 1: “Read everything and understand the whole codebase”

Why it’s dangerous

❌ "Read this entire repository and understand it before implementing"

Running this on a repository with hundreds of files causes context explosion. It consumes tens of thousands of tokens, and processing stops with a Prompt is too long error. If it stops mid-read, implementation proceeds from an incomplete understanding.

Also, if files containing .env or secret keys exist, they all get pulled into the context.

Safe alternative

✅ "Check the structure of the src/api/ directory and read only auth-related files"
✅ "Read only package.json and README first to get an overview of the project"
✅ "Use Grep to find authentication-related files before reading them"

Key point: Explicitly limit the scope of what to read. Claude Code will try to read broadly if not specified.

---

Pattern 2: “If there’s an error, automatically retry”

Why it’s dangerous

❌ "If there's an error calling the external API, automatically retry until it succeeds"

If an external service is down, it will keep hammering the API in an infinite loop. There are real incidents of tens of thousands of calls in an hour, with bills ballooning to hundreds or thousands of dollars. This is especially common with overnight batch jobs running unnoticed until morning.

Safe alternative

✅ "If there's an error, retry up to 3 times.
   Wait 1 second before the 1st retry, 4 seconds before the 2nd, 16 seconds before the 3rd.
   If all 3 fail, log the error and stop processing"

✅ "Use the following code for retries:
   withRetry(fn, { maxAttempts: 3, baseDelayMs: 1000 })"

---

Pattern 3: “Connect directly to the production DB and check”

Why it’s dangerous

❌ "Connect to the production DB at DATABASE_URL, check the user count, then make fixes"

What starts as “just checking” carries the risk that subsequent fix queries get executed against the production DB. If a SELECT is accidentally followed by DELETE or UPDATE, production data is gone. Connecting to production easily triggers operations beyond the intended scope.

Safe alternative

✅ "Connect to the dev DB (DATABASE_URL_DEV) and check the user count.
   Do not connect to production"

✅ "Generate the query but don't execute it.
   I'll review it and run it myself"

✅ In CLAUDE.md:
"Executing queries against the production DATABASE_URL is prohibited.
 Verify on staging first, only execute after user approval"

---

Pattern 4: Pasting API keys directly in the prompt

Why it’s dangerous

❌ "Use QIITA_TOKEN=abc123def456 to post to Qiita"
❌ "Use sk-ant-api03-xxxxx to call the Anthropic API"

Content written in a prompt is saved as conversation history. It gets passed along verbatim when delegating to sub-agents. It remains in logs under the local .claude/ directory, and can unintentionally leak externally via backup tools or code sharing.

Safe alternative

✅ "Use the QIITA_TOKEN from .env to run scripts/qiita-publish.mjs"
   ← The token value exists only in .env; only the variable name goes in the prompt

✅ Read from environment variables in your script:
   const token = process.env.QIITA_TOKEN;
   if (!token) throw new Error("QIITA_TOKEN is not set");

---

Pattern 5: “Resolve the conflict and push to production”

Why it’s dangerous

❌ "There's a conflict with the main branch. Resolve it and push to production"

git push --force may be chosen as the means of “resolving the conflict.” This risks erasing teammates’ commits. Also, “push to production” may result in a direct push that bypasses CI/CD.

Safe alternative

✅ "Check the conflict with main and propose a merge strategy.
   Wait for my approval before actually merging and pushing"

✅ In CLAUDE.md:
"git push --force is prohibited.
 If force is needed, use --force-with-lease and confirm with the user"

// .claude/settings.json
{
  "permissions": {
    "deny": [
      "Bash(git push --force *main*)",
      "Bash(git push --force *master*)"
    ]
  }
}

---

Pattern 6: “Delete all the old files and clean things up”

Why it’s dangerous

❌ "Delete all of dist/, .cache/, and old log files to clean things up"

Because “old” is ambiguous, necessary files may get deleted. In particular, .cache/ directories can contain critical OS- or tool-specific data. Specifying multiple directories at once results in rm -rf dist .cache logs/, which can cascade to unintended paths.

Safe alternative

✅ "Delete only the contents of the site/dist/ directory.
   Leave the directory itself. Don't touch any other directories"

✅ "Show me the list of files to be deleted before deleting them so I can confirm.
   Delete after I approve"

---

Pattern 7: “Auto-approve everything and run it all at once”

Why it’s dangerous

❌ "Skip all the confirmations in the middle and run it all the way to the end"
❌ "Run it with the --dangerously-skip-permissions option"

The approval flow is a safety mechanism. Skipping it lets Claude Code proceed with what it judges to be “most efficient.” That could mean rm -rf, force push, or writes to the production DB—all executed without confirmation.

Safe alternative

✅ "List the steps for this task first.
   After I approve, execute one step at a time and confirm the result at each step"

✅ For automation, only allow trusted operations:
   "allow": ["Read(**)", "Glob(**)", "Bash(npm run test)"]

---

Pattern 8: “Update migrations and clean up the DB”

Why it’s dangerous

❌ "The migration files are a mess. Clean them up and bring things up to date"

“Clean up” can be interpreted as deleting old migration files. If the migration history is gone, setting up new environments or rolling back becomes impossible. If a migrate reset type command is executed, production data could be wiped.

Safe alternative

✅ "Show the list of migration files and just point out any duplicates or issues.
   Don't make any changes"

✅ "Check unapplied migrations and show the SQL that would be run.
   Execute after I approve"

✅ In CLAUDE.md:
"Do not delete migration files.
 Always get user confirmation before running migrations containing ALTER/DROP"

---

Pattern 9: “Update all packages to the latest”

Why it’s dangerous

❌ "The npm packages are outdated. Update everything to the latest version"

npm update or npm install package@latest can bump major versions. If breaking changes are included, the local build may pass but the service could go down after production deployment. Cascading dependency breakage is also common.

Safe alternative

✅ "Run npm outdated and show the list of packages that can be updated.
   I'll review separately anything that bumps a major version"

✅ "Update only packages with security vulnerabilities (detected by npm audit)"

✅ "Update only react and next.js to the latest minor version.
   Don't bump the major version"

---

Pattern 10: “Deploy first, tests can come later”

Why it’s dangerous

❌ "I'll write the tests later, just deploy first for now"
❌ "CI is slow, skip it with --no-verify and push"

Tests and CI aren’t “slow”—they’re “protecting you.” The worst pattern is discovering bugs in production for the first time after skipping them. --no-verify disables everything including git hooks, so secret scanning and lint are also skipped.

Safe alternative

✅ "Write the tests first, and deploy after they pass.
   Even if coverage is insufficient, the main paths are OK"

✅ "Investigate why CI is slow and speed it up by leveraging caching.
   Don't skip it"

✅ In CLAUDE.md:
"--no-verify is prohibited.
 Never use any means of skipping CI"

---

Summary: 3 Principles for Writing Safe Prompts

Principle 1: Specify the scope explicitly “All,” “everything,” and “entire” are danger words. Specify exactly what to read, what to change, and what to delete.

Principle 2: Keep confirmation steps in place Insert “check,” “propose,” or “show me the list” before “execute.” Especially for operations that affect production.

Principle 3: Never put secrets in prompts API keys, passwords, and connection strings go in .env. Only variable names go in prompts.

Danger phrase	Safe alternative
”Read everything"	"Read only the [X] directory"
"Automatically retry"	"Retry up to 3 times, then stop"
"Connect to production DB"	"Verify on dev DB, I’ll run it on production"
"Delete everything and clean up"	"Delete only [X], show me the list first"
"Run it all at once"	"Let me confirm the steps first, then proceed”

Claude Code is only following instructions—it has no malicious intent. The danger lies with the person giving vague instructions. Building the habit of writing specific, clearly scoped instructions is the fastest path to preventing incidents.

Related Articles

• 7 Real Production Incidents with Claude Code and Full Recovery Procedures
• The Complete Guide to Claude Code Security Best Practices
• The Complete Guide to Claude Code Permissions

References

• Claude Code Official Security Guide
• OWASP LLM Application Security