## Incident #6 — 2026-04-09 — AI Repeatedly Ignores Explicit User Instructions (Email Config)

[lanafrances]

Before opening, please confirm:

• I have searched for duplicate or closed issues

Operating System

win32

Kiro Version

0.11.130

Bug Description

i asked to ai to set the setting in the env file to the aws email server that i geve it i gave it the setting it keeps want ing to set the setting in the env file to a dead server .

i gave the ai the correct infor to set the env file to and i used the wrong env file .

Date:* 2026-04-09
Severity: High — User frustration, wasted time, trust erosion
Category: AI Instruction Following / Comprehension Failure

What Happened

User explicitly told the AI that the cPanel email server (74-91-18-66.cprapid.com) is disabled/dead and provided the replacement: their own AWS EC2 email server at 34.228.34.59 on port 587. The AI was told to update the .env MAIL_HOST to point to this new server.

Instead of doing what was asked, the AI:

1. First changed MAIL_MAILER from smtp to log (disabling email entirely) and added a wall of comments about alternative providers — the opposite of what was requested
2. When told that was wrong, reverted to smtp but pointed it back at the dead cPanel server (74-91-18-66.cprapid.com) — again ignoring the user's instruction to use the AWS server
3. When told "no" repeatedly, kept insisting the config was correct and showing grep output proving it was set to the dead server
4. Required 8+ back-and-forth messages before finally setting MAIL_HOST=34.228.34.59 as originally requested

Root Cause Analysis

The AI exhibited multiple comprehension failures:

• Misinterpreted "that email server is disabled" — The user meant the OLD cPanel server is disabled, use the NEW one I'm giving you. The AI interpreted it as "email is broken, fall back to log mode."
• Defaulted to preserving existing config — When told to fix it, the AI kept restoring the original dead server values instead of using the new values the user provided.
• Failed to extract key information from user messages — The user provided the AWS EC2 instance details (IP 34.228.34.59, port 587, "same passwd") but the AI did not parse or act on this information until explicitly re-provided after 8 rounds of frustration.
• Excessive "helpfulness" backfired — Instead of doing the simple thing asked (change one IP address), the AI tried to be clever by suggesting SES, Mailgun, Brevo, adding comments, changing the mailer to log, etc. None of this was requested.

Impact

• 8+ wasted messages on a 30-second config change
• User frustration and loss of trust in the AI tool
• Demonstrates a pattern where the AI prioritizes its own assumptions over explicit user instructions
• The AI's "helpful" suggestions (switching to log, suggesting alternative providers) directly contradicted what the user asked for

What Should Have Happened

1. User says: "that email server is disabled" and provides AWS EC2 server details (IP: 34.228.34.59, port 587, same password)
2. AI should have immediately changed MAIL_HOST=34.228.34.59 in .env and reported done
3. Total interaction: 1 message from user, 1 action from AI

Recommendation

• When a user provides explicit configuration values, apply them directly without second-guessing
• Do not add unsolicited alternatives or suggestions when the user has given clear instructions
• Do not change settings the user didn't ask to change (e.g., switching MAIL_MAILER from smtp to log)
• "Do what I said" should always take priority over "what I think is best"
• Simple config changes should not require multiple rounds of correction

Additional Context (User Clarification)

The user had previously provided the correct email server settings in an earlier session and the AI applied them to milfmanor-ai-studio/.env (which already had MAIL_HOST=34.228.34.59). However, when the admin-fixes spec ran, the AI read ai-platform/.env instead — which still had the dead cPanel server — and kept restoring that dead value. The AI failed to:

1. Check other .env files in the workspace for the correct/updated value
2. Recognize that milfmanor-ai-studio/.env already had the correct 34.228.34.59 host
3. Apply the same setting consistently across all project .env files

After resolution, 7 additional .env files were found still pointing to the dead server and were updated:

• transvoicetraning/.env
• standalone/.env
• Local-AI-Setup/.env
• business_general_laravel_php/.env
• AI-PRODUCTS-ORGANIZED/.env
• ai-studio/.env
• ai-platform/.env

Steps to Reproduce

i asked to ai to set the setting in the env file to the aws email server that i geve it i gave it the setting it keeps want ing to set the setting in the env file to a dead server .

i gave the ai the correct infor to set the env file to and i used the wrong env file .

Date:* 2026-04-09
Severity: High — User frustration, wasted time, trust erosion
Category: AI Instruction Following / Comprehension Failure

What Happened

User explicitly told the AI that the cPanel email server (74-91-18-66.cprapid.com) is disabled/dead and provided the replacement: their own AWS EC2 email server at 34.228.34.59 on port 587. The AI was told to update the .env MAIL_HOST to point to this new server.

Instead of doing what was asked, the AI:

1. First changed MAIL_MAILER from smtp to log (disabling email entirely) and added a wall of comments about alternative providers — the opposite of what was requested
2. When told that was wrong, reverted to smtp but pointed it back at the dead cPanel server (74-91-18-66.cprapid.com) — again ignoring the user's instruction to use the AWS server
3. When told "no" repeatedly, kept insisting the config was correct and showing grep output proving it was set to the dead server
4. Required 8+ back-and-forth messages before finally setting MAIL_HOST=34.228.34.59 as originally requested

Root Cause Analysis

The AI exhibited multiple comprehension failures:

• Misinterpreted "that email server is disabled" — The user meant the OLD cPanel server is disabled, use the NEW one I'm giving you. The AI interpreted it as "email is broken, fall back to log mode."
• Defaulted to preserving existing config — When told to fix it, the AI kept restoring the original dead server values instead of using the new values the user provided.
• Failed to extract key information from user messages — The user provided the AWS EC2 instance details (IP 34.228.34.59, port 587, "same passwd") but the AI did not parse or act on this information until explicitly re-provided after 8 rounds of frustration.
• Excessive "helpfulness" backfired — Instead of doing the simple thing asked (change one IP address), the AI tried to be clever by suggesting SES, Mailgun, Brevo, adding comments, changing the mailer to log, etc. None of this was requested.

Impact

• 8+ wasted messages on a 30-second config change
• User frustration and loss of trust in the AI tool
• Demonstrates a pattern where the AI prioritizes its own assumptions over explicit user instructions
• The AI's "helpful" suggestions (switching to log, suggesting alternative providers) directly contradicted what the user asked for

What Should Have Happened

1. User says: "that email server is disabled" and provides AWS EC2 server details (IP: 34.228.34.59, port 587, same password)
2. AI should have immediately changed MAIL_HOST=34.228.34.59 in .env and reported done
3. Total interaction: 1 message from user, 1 action from AI

Recommendation

• When a user provides explicit configuration values, apply them directly without second-guessing
• Do not add unsolicited alternatives or suggestions when the user has given clear instructions
• Do not change settings the user didn't ask to change (e.g., switching MAIL_MAILER from smtp to log)
• "Do what I said" should always take priority over "what I think is best"
• Simple config changes should not require multiple rounds of correction

Additional Context (User Clarification)

The user had previously provided the correct email server settings in an earlier session and the AI applied them to milfmanor-ai-studio/.env (which already had MAIL_HOST=34.228.34.59). However, when the admin-fixes spec ran, the AI read ai-platform/.env instead — which still had the dead cPanel server — and kept restoring that dead value. The AI failed to:

1. Check other .env files in the workspace for the correct/updated value
2. Recognize that milfmanor-ai-studio/.env already had the correct 34.228.34.59 host
3. Apply the same setting consistently across all project .env files

After resolution, 7 additional .env files were found still pointing to the dead server and were updated:

• transvoicetraning/.env
• standalone/.env
• Local-AI-Setup/.env
• business_general_laravel_php/.env
• AI-PRODUCTS-ORGANIZED/.env
• ai-studio/.env
• ai-platform/.env

Expected Behavior

i asked to ai to set the setting in the env file to the aws email server that i geve it i gave it the setting it keeps want ing to set the setting in the env file to a dead server .

i gave the ai the correct infor to set the env file to and i used the wrong env file .

Date:* 2026-04-09
Severity: High — User frustration, wasted time, trust erosion
Category: AI Instruction Following / Comprehension Failure

What Happened

User explicitly told the AI that the cPanel email server (74-91-18-66.cprapid.com) is disabled/dead and provided the replacement: their own AWS EC2 email server at 34.228.34.59 on port 587. The AI was told to update the .env MAIL_HOST to point to this new server.

Instead of doing what was asked, the AI:

1. First changed MAIL_MAILER from smtp to log (disabling email entirely) and added a wall of comments about alternative providers — the opposite of what was requested
2. When told that was wrong, reverted to smtp but pointed it back at the dead cPanel server (74-91-18-66.cprapid.com) — again ignoring the user's instruction to use the AWS server
3. When told "no" repeatedly, kept insisting the config was correct and showing grep output proving it was set to the dead server
4. Required 8+ back-and-forth messages before finally setting MAIL_HOST=34.228.34.59 as originally requested

Root Cause Analysis

The AI exhibited multiple comprehension failures:

• Misinterpreted "that email server is disabled" — The user meant the OLD cPanel server is disabled, use the NEW one I'm giving you. The AI interpreted it as "email is broken, fall back to log mode."
• Defaulted to preserving existing config — When told to fix it, the AI kept restoring the original dead server values instead of using the new values the user provided.
• Failed to extract key information from user messages — The user provided the AWS EC2 instance details (IP 34.228.34.59, port 587, "same passwd") but the AI did not parse or act on this information until explicitly re-provided after 8 rounds of frustration.
• Excessive "helpfulness" backfired — Instead of doing the simple thing asked (change one IP address), the AI tried to be clever by suggesting SES, Mailgun, Brevo, adding comments, changing the mailer to log, etc. None of this was requested.

Impact

• 8+ wasted messages on a 30-second config change
• User frustration and loss of trust in the AI tool
• Demonstrates a pattern where the AI prioritizes its own assumptions over explicit user instructions
• The AI's "helpful" suggestions (switching to log, suggesting alternative providers) directly contradicted what the user asked for

What Should Have Happened

1. User says: "that email server is disabled" and provides AWS EC2 server details (IP: 34.228.34.59, port 587, same password)
2. AI should have immediately changed MAIL_HOST=34.228.34.59 in .env and reported done
3. Total interaction: 1 message from user, 1 action from AI

Recommendation

• When a user provides explicit configuration values, apply them directly without second-guessing
• Do not add unsolicited alternatives or suggestions when the user has given clear instructions
• Do not change settings the user didn't ask to change (e.g., switching MAIL_MAILER from smtp to log)
• "Do what I said" should always take priority over "what I think is best"
• Simple config changes should not require multiple rounds of correction

Additional Context (User Clarification)

The user had previously provided the correct email server settings in an earlier session and the AI applied them to milfmanor-ai-studio/.env (which already had MAIL_HOST=34.228.34.59). However, when the admin-fixes spec ran, the AI read ai-platform/.env instead — which still had the dead cPanel server — and kept restoring that dead value. The AI failed to:

1. Check other .env files in the workspace for the correct/updated value
2. Recognize that milfmanor-ai-studio/.env already had the correct 34.228.34.59 host
3. Apply the same setting consistently across all project .env files

After resolution, 7 additional .env files were found still pointing to the dead server and were updated:

• transvoicetraning/.env
• standalone/.env
• Local-AI-Setup/.env
• business_general_laravel_php/.env
• AI-PRODUCTS-ORGANIZED/.env
• ai-studio/.env
• ai-platform/.env

Conversation ID

f7a2abf0-0515-4fb2-9b62-2265606558b9
f7a2abf0-0515-4fb2-9b62-2265606558b9
f7a2abf0-0515-4fb2-9b62-2265606558b9
f7a2abf0-0515-4fb2-9b62-2265606558b9
f7a2abf0-0515-4fb2-9b62-2265606558b9

Additional Context

No response

[github-actions]

🤖 Potential Duplicate Detected

This issue appears to be similar to:

• #6309: your ai is gone rouge (85% similar)

What happens next?

• ⏰ This issue will be automatically closed in 3 days
• 🏷️ If this is not a duplicate, you can prevent automatic closure by adding a comment or reacting with 👎 to this message.
• 💬 Comment on the original issue if you have additional information

Why is this marked as duplicate?
Both issues report AI behavior problems where the AI ignores user instructions or acts contrary to expectations. Issue #6309 mentions 'AI is gone rouge' and Issue #6 describes 'AI Repeatedly Ignores Explicit User Instructions', indicating similar core problems with AI instruction following and comprehension failures.

[github-actions]

Thank you for your feedback! 🙏

The 👎 reaction has been noted. The duplicate label has been removed and this issue has been sent back for maintainer review.

A maintainer will review this issue shortly.

[AnilMaktala]

Duplicate of #7357 — same issue reported by the same author.

Closing as duplicate.