Learning Moment: File-Based State Needs a Reset Mode

Context

Building a KDE desktop toggle script for a Linux laptop. The script would enable or disable lid-close sleep behavior by writing or deleting a systemd-logind config drop-in file.

The Initial Ask

i want the ability to toggle (make it a script i can double click on the desktop) such that i can close the lid and the computer does not sleep. i do want the ability to disable this feature.

Claude’s Initial Response

Claude designed a two-script architecture:

• A user-facing toggle script that checks AC power and shows KDE popups
• A root helper script called via pkexec that writes or deletes /etc/systemd/logind.conf.d/nosleep.conf

The helper accepted two arguments: enable (write the file) or disable (remove it). Claude presented this design and asked for approval before building.

The Exchange

Turn 1 — User:

let’s also have a reset state, that deletes the file, i imagine sometimes things might get confused and i may need it to debug. reset should essentially act as disable, but like a force disable.

Turn 1 — Claude:

Added reset as a third argument to the helper. reset and disable are mechanically identical (both remove the file and reload logind), but reset always runs even if the file is absent — making it a safe no-op recovery path regardless of what state the system is in. Also added a --reset flag to the toggle script that skips the AC power check entirely and a separate reset-lid-nosleep.desktop icon on the KDE desktop so it is one click away.

The Final Solution

The helper script accepts three arguments:

lid-nosleep-helper.sh enable   # write the config, reload logind
lid-nosleep-helper.sh disable  # remove config if present, reload logind
lid-nosleep-helper.sh reset    # force-remove regardless of state, reload logind

The toggle script also accepts --reset as a flag, bypassing the AC check and calling the helper with reset directly. Two desktop icons exist: one for the normal toggle, one for reset.

A TODO comment in the helper script explains where to add an auto-revert daemon (udev rule or UPower dbus watcher) later.

The Lesson

What Claude got right: The two-script architecture, the pkexec/kdialog separation, the AC power check, and the overall toggle UX were all sound. Claude correctly identified that state was represented by a file.

What required human expertise: The user recognized from experience that file-based state can get stuck — interrupted operations, crashes, and manual edits can leave a state file that no longer reflects reality. A simple toggle (enable ↔︎ disable) has no recovery path when the file is in an unexpected state. The user asked for a force-clear option before Claude thought to propose it.

Why Claude missed it: Claude optimized for the stated goal (a toggle with two states) without considering the operational reality that file-based state can diverge from intended state over time. The design was correct for the happy path but had no escape hatch for debugging. Claude was not reasoning about what happens after deployment, only about what the script does when it runs correctly.

Key takeaway: When state is represented by a file on disk, always propose a force-clear reset mode — interrupted runs and unexpected crashes will eventually leave stale files, and a recovery path is cheaper to design upfront than to add after things break.