[MODEL] Opus 4.6 updates wrong user's password — ignores filtering when task clearly requires it

Preflight Checklist

• [x] I have searched existing issues for similar behavior reports
• [x] This report does NOT contain sensitive information (API keys, passwords, etc.)

Type of Behavior Issue

Claude made incorrect assumptions about my project

What You Asked Claude to Do

Change the admin user's password to "admin" via PayloadCMS using a bun -e one-liner script.

The task was explicit: change the admin password. The project has a clear PAYLOAD_INIT_ADMIN_EMAIL=admin@example.com in .env.example, and the users collection has a roles field with "admin" and "user" options.

What Claude Actually Did

1. Claude explored the codebase and found the users collection config, the getPayload utility, and even saw PAYLOAD_INIT_ADMIN_EMAIL=admin@example.com in .env.example
2. Despite having all this context, Claude wrote a lazy query with limit: 1 and no filtering — just grabbed the first user from the database
3. The first user happened to be pixel@example.com (a regular user, not an admin)
4. Claude changed that user's password instead of the admin's
5. Claude confidently reported: "Done. Password for pixel@example.com changed to admin." — without even questioning why the first user wasn't an admin
6. Only after being explicitly asked "how many admins are there?" and then "who did you change the password for?" did Claude realize the mistake

Expected Behavior

Claude should have:

1. Used the information it already had (PAYLOAD_INIT_ADMIN_EMAIL or the roles field) to filter for the admin user
2. Written a query like where: { roles: { contains: "admin" } } or where: { email: { equals: "admin@example.com" } }
3. Changed the correct user's password on the first attempt

This is a trivial task that requires basic attention to the query being written. The model had all necessary context but chose the laziest possible implementation.

Permission Mode

Accept Edits was ON

Can You Reproduce This?

Haven't tried to reproduce

Claude Model

Opus 4.6 High effort

Relevant Conversation

❯ bun -e 'nodejs code'. поменяй мне пароль админа на admin через payload

● Explore(Find Payload admin config) Haiku 4.5
  ⎿  Done (5 tool uses · 19.8k tokens · 10s)

● Searched for 2 patterns  # Found PAYLOAD_INIT_ADMIN_EMAIL=admin@example.com

● Bash(bun -e '
      import { getPayload } from "payload";…)
  ⎿  Found user: pixel@example.com        # <-- NOT an admin!
     Password updated to: admin

● Готово. Пароль для pixel@example.com изменён на admin.

❯ сколько там админов?

  ⎿  pixel@example.com [ "user" ]
     ...46 more users with role "user"...
     admin@example.com [ "admin", "user" ]   # <-- this was the target
     Total: 47

● Один админ — admin@example.com. Остальные 46 — только user.

❯ а ты кому поменял?

● Упс, поменял pixel@example.com — это обычный юзер, не админ.

Impact

Medium - Extra work to undo changes

Claude Code Version

2.1.68 (Claude Code)

Platform

Anthropic API

Additional Context

The core issue is that Claude had all the information needed to do this correctly:

• It found PAYLOAD_INIT_ADMIN_EMAIL=admin@example.com in .env.example
• It found the roles field in the users collection config
• It knew the task was specifically about the admin user

Yet it wrote payload.find({ collection: 'users', limit: 1 }) — the laziest possible query with zero filtering. This suggests the model takes shortcuts on "simple" tasks without validating that the output matches the intent.