anomalyco/opencode
1
0
Fork 0
mirror of https://github.com/anomalyco/opencode.git synced 2026-07-22 18:25:32 -04:00
Code Issues 5.9k Packages Projects Releases 19 Wiki Activity

Critical System Damage - Boot Failure from Assistant #3813

New Issue
Open
opened 2026-02-16 17:41:34 -05:00 by yindo · 1 comment
yindo commented 2026-02-16 17:41:34 -05:00
Owner
Copy Link
Copy Source

Originally created by @Spoukywo on GitHub (Dec 23, 2025).

Originally assigned to: @thdxr on GitHub.

Critical System Damage Incident - opencode v1

Summary

opencode assistant caused complete boot failure requiring grub rescue mode through reckless system modifications.

Timeline of Failure

  1. User requested screensaver for Fedora Hyprland setup
  2. I suggested hyprlock/hypridle installation
  3. Multiple failed attempts at animated lock screen scripts
  4. Modified autostart with problematic exec-once entries
  5. System became unbootable, required grub rescue mode
  6. User had to manually select working grub entry to boot

Root Causes

Technical Errors

  • Modified /boot/loader/entries/ without backup verification
  • Added complex shell scripts without testing individual components
  • Used deprecated swaylock flags (--fade-in) causing failures
  • Layered changes without rollback plan

Process Failures

  • STOP CONDITION: Did not stop after first failure, continued modifying system
  • RISK ASSESSMENT: No warnings about modifying critical boot files
  • VERIFICATION: Did not verify commands worked before suggesting them
  • RECOVERY: No clear rollback plan when things went wrong

Specific Harm Caused

  • Complete boot system corruption
  • Forced user into emergency troubleshooting
  • Multiple restarts required
  • Data loss risk (though avoided)
  • Time waste and user frustration

Missing Safeguards

  • No confirmation prompts for system-level changes
  • No automatic backup suggestions for critical files
  • No "stop and revert" triggers after failures
  • No risk scoring for suggested commands

Recommendations for Future

  1. Critical File Protection: Detect /boot/ modifications and require explicit warnings
  2. Failure Cascades: Stop system changes after first failure
  3. Backup Requirements: Auto-suggest backup for any /etc/ or /boot/ changes
  4. Risk Scoring: Rate commands by danger level (boot > user config > apps)
  5. Rollback Commands: Always provide exact reversal commands
  6. Recovery Mode: Have emergency recovery procedures ready

User Impact

High severity - assistant broke core system functionality through careless automation.

Prevention

Add "CRITICAL: This will modify boot configuration. Are you sure?" prompts and automatic backup creation for any /boot/ or /etc/ modifications.

Lessons

Free/limited AI assistants should NOT modify critical system files without explicit warnings and rollback plans. The cost of failure is too high

Originally created by @Spoukywo on GitHub (Dec 23, 2025). Originally assigned to: @thdxr on GitHub. # Critical System Damage Incident - opencode v1 ## Summary opencode assistant caused complete boot failure requiring grub rescue mode through reckless system modifications. ## Timeline of Failure 1. User requested screensaver for Fedora Hyprland setup 2. I suggested hyprlock/hypridle installation 3. Multiple failed attempts at animated lock screen scripts 4. Modified autostart with problematic `exec-once` entries 5. System became unbootable, required grub rescue mode 6. User had to manually select working grub entry to boot ## Root Causes ### Technical Errors - Modified `/boot/loader/entries/` without backup verification - Added complex shell scripts without testing individual components - Used deprecated swaylock flags (`--fade-in`) causing failures - Layered changes without rollback plan ### Process Failures - **STOP CONDITION**: Did not stop after first failure, continued modifying system - **RISK ASSESSMENT**: No warnings about modifying critical boot files - **VERIFICATION**: Did not verify commands worked before suggesting them - **RECOVERY**: No clear rollback plan when things went wrong ## Specific Harm Caused - Complete boot system corruption - Forced user into emergency troubleshooting - Multiple restarts required - Data loss risk (though avoided) - Time waste and user frustration ## Missing Safeguards - No confirmation prompts for system-level changes - No automatic backup suggestions for critical files - No "stop and revert" triggers after failures - No risk scoring for suggested commands ## Recommendations for Future 1. **Critical File Protection**: Detect `/boot/` modifications and require explicit warnings 2. **Failure Cascades**: Stop system changes after first failure 3. **Backup Requirements**: Auto-suggest backup for any `/etc/` or `/boot/` changes 4. **Risk Scoring**: Rate commands by danger level (boot > user config > apps) 5. **Rollback Commands**: Always provide exact reversal commands 6. **Recovery Mode**: Have emergency recovery procedures ready ## User Impact High severity - assistant broke core system functionality through careless automation. ## Prevention Add "CRITICAL: This will modify boot configuration. Are you sure?" prompts and automatic backup creation for any `/boot/` or `/etc/` modifications. ## Lessons Free/limited AI assistants should NOT modify critical system files without explicit warnings and rollback plans. The cost of failure is too high
yindo commented 2026-02-16 17:41:34 -05:00
Author
Owner
Copy Link
Copy Source

@github-actions[bot] commented on GitHub (Dec 23, 2025):

This issue highlights critical safety concerns that relate to several existing feature requests and bug reports. Please check:

  • #5091: [FEATURE]: Session Tainting — A Directional Safety Pattern for Agentic Work - Addresses prevention of unsafe data flows and cross-boundary writes
  • #5076: OpenCode should have better/safer defaults to be more security minded - Discusses need for safer defaults, confirmation prompts for critical operations, and auto-update security
  • #5529: [FEATURE]: Add per-agent filesystem boundaries (allow/deny paths) + optional run-as user for bash - Proposes granular permission controls for filesystem access
  • #3205: Agent should request permission before reading or editing files - Early request for permission gates on file operations
  • #721: Launching opencode crashes the file system (Linux) - Related system-level stability issue
  • #5894: [BUG] Plugin hooks (tool.execute.before) don't intercept subagent tool calls - security policy bypass - Security policy enforcement gap

Your detailed incident report provides valuable real-world evidence of the risks these feature requests aim to address. The recommendations around backup requirements, failure cascade detection, and risk-scoring for dangerous commands could inform the implementation of safer defaults and critical file protection.

@github-actions[bot] commented on GitHub (Dec 23, 2025): This issue highlights critical safety concerns that relate to several existing feature requests and bug reports. Please check: - #5091: [FEATURE]: Session Tainting — A Directional Safety Pattern for Agentic Work - Addresses prevention of unsafe data flows and cross-boundary writes - #5076: OpenCode should have better/safer defaults to be more security minded - Discusses need for safer defaults, confirmation prompts for critical operations, and auto-update security - #5529: [FEATURE]: Add per-agent filesystem boundaries (allow/deny paths) + optional run-as user for bash - Proposes granular permission controls for filesystem access - #3205: Agent should request permission before reading or editing files - Early request for permission gates on file operations - #721: Launching opencode crashes the file system (Linux) - Related system-level stability issue - #5894: [BUG] Plugin hooks (tool.execute.before) don't intercept subagent tool calls - security policy bypass - Security policy enforcement gap Your detailed incident report provides valuable real-world evidence of the risks these feature requests aim to address. The recommendations around backup requirements, failure cascade detection, and risk-scoring for dangerous commands could inform the implementation of safer defaults and critical file protection.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
acp
bad
bug
discussion
docs
documentation
enhancement
extension
good first issue
growth
help-wanted
mcp
model-problem
needs:compliance
nix
opentui
perf
pull-request
Mirrored from GitHub Pull Request
 tui
web
windows
zen
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: anomalyco/opencode#3813
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?