It started as a joke. My system felt sluggish, and I was too lazy to actually debug it. So I typed "Why does my computer feel so slow?" into Claude Code, half expecting a generic "have you tried rebooting" response.
Instead, I watched Claude request permission to read /etc/pacman.conf.
Wait. What?
Can Claude... read my filesystem? Like, my actual system configuration files? The ones I half-forgot existed and never dared to touch because I have no idea what they do?
Quick context: I'm not a Linux veteran. I tried Ubuntu for two weeks back in 2004 and gave up. Only started daily-driving Arch in spring 2025 thanks to the YouTube algorithm, which for some unexplainable reason started recommending Arch-related videos. Most system configs still feel like nordic runes mixed with tech-sorcery to me.
Yes. Yes it can. And that realization changed how I use AI completely.
I run Arch Linux with Omarchy - DHH's opinionated Hyprland setup. But the first experiments weren't about Omarchy at all. They were about the boring stuff. The stuff you set up once, forget about, and never optimize because "it works."
Turns out, "it works" and "it works well" are very different things.
The system optimizations I never knew I needed
Let me start with the stuff that has nothing to do with desktop environments or window managers. Just pure Linux system optimization that Claude Code helped me discover.
Pacman on steroids
I asked Claude to optimize my pacman configuration based on my internet speed. It ran a speed test, calculated optimal parallel downloads, and configured things I didn't know existed.
# /etc/pacman.conf
ParallelDownloads = 10
Color
VerbosePkgLists
ILoveCandy # Yes, Claude added this. It turns the progress bar into Pac-Man.System updates went from "go make coffee" to "barely enough time to alt-tab." The ILoveCandy flag was unsolicited but deeply appreciated.
It also checked my makepkg.conf and made sure zstd compression uses all CPU cores with -T0. Building packages from AUR went from "time for a coffee break" to "maybe I'll just wait."
Shell that actually helps you
I asked Claude what bash optimizations I was missing. It added a bunch of quality-of-life improvements I didn't know existed:
# ─── Bash optimeringar ───────────────────────────────────────
# Navigation
shopt -s autocd # type directory name to cd into it
shopt -s cdspell # autocorrect typos in cd
shopt -s dirspell # autocorrect typos in tab-completion
# Globbing
shopt -s globstar # ** matches recursively (e.g. **/*.js)
shopt -s nocaseglob # case-insensitive globbing
# History
shopt -s histverify # show command before running with !!
HISTTIMEFORMAT="%F %T " # timestamps in history
# Completion
bind "set completion-ignore-case on"
bind "set show-all-if-ambiguous on"
bind "set mark-symlinked-directories on"The autocd one alone saves me dozens of keystrokes daily. Just type a directory name and hit enter. No cd required. And globstar means **/*.tsx actually works instead of giving me nothing.
Claude also optimized my Starship prompt config with a 200ms command timeout - fast enough that you never notice it waiting, but generous enough that git status still works in large repos.
The filesystem I didn't know I had
When I asked Claude to check my disk setup, it pointed out something I'd forgotten: I'm running btrfs with transparent compression. The fstab tells the story:
# /etc/fstab - btrfs with all the good stuff
UUID=... / btrfs rw,relatime,compress=zstd:3,ssd,space_cache=v2,subvol=/@ 0 0
UUID=... /home btrfs rw,relatime,compress=zstd:3,ssd,space_cache=v2,subvol=/@home 0 0
UUID=... /var/cache/pacman/pkg btrfs rw,relatime,compress=zstd:3,ssd,space_cache=v2,subvol=/@pkg 0 0
UUID=... /var/log btrfs rw,relatime,compress=zstd:3,ssd,space_cache=v2,subvol=/@log 0 0Separate subvolumes for root, home, package cache, and logs. Zstd compression level 3. SSD optimizations. Space cache v2. This was set up during Omarchy installation, but I had no idea what it actually meant until Claude explained it.
Speaking of package cache - Claude found 12GB of old packages sitting there. Set up automatic cleanup and suddenly I had space again:
# Set up automatic package cache cleaning
sudo pacman -S pacman-contrib
sudo systemctl enable paccache.timer
# Or clean manually - keep only 2 most recent versions
paccache -rThe collaborative debugging experience
Here's what surprised me most. Claude Code with system access isn't just about running commands. It's about diagnosing problems in ways I wouldn't have thought to try.
Me: "My terminal feels sluggish when I cd into my project directory"
Claude: *checks .bashrc for expensive operations*
*examines git prompt configuration*
*tests startup time with and without certain configs*
"Your git prompt is running 'git status' on every command, and your
project has 50,000 files. Here are three options:
1. Use an async git prompt (adds ~2 lines to config)
2. Disable git status in large repos (conditional in .bashrc)
3. Use a different prompt framework with better caching
Option 1 is probably best for your workflow. Want me to set it up?"That's not code generation. That's diagnosis, explanation, and collaborative problem-solving. The conversation shifts from "write me a function" to "help me understand why my system behaves this way."
Then came Omarchy, and everything leveled up
All the stuff above? Claude figured it out from general Linux knowledge. But then I discovered that Omarchy ships with something special: a Claude Code skill specifically designed for the system.
A 400+ line instruction set that teaches Claude exactly how to work with every part of the Omarchy ecosystem. Where configs live. Which commands exist. What's safe to edit and what will break your system.
name: Omarchy
description: >
REQUIRED for ANY changes to Linux desktop, window manager, or system config.
Use when editing ~/.config/hypr/, ~/.config/waybar/, ~/.config/walker/,
~/.config/alacritty/, ~/.config/kitty/, ~/.config/ghostty/, ~/.config/mako/,
or ~/.config/omarchy/.This isn't a generic "here's how Linux works" prompt. It's a complete map of Omarchy. The skill even knows that Waybar doesn't auto-reload on config changes but Hyprland does - the kind of detail that saves you from that "why isn't this working" panic.
Window manager tweaks without wiki diving
I wanted to change how my windows animate when opening. Old me would have spent 20 minutes in the Hyprland wiki, cross-referencing syntax that changes between versions. New me:
Me: "Make window open animations faster and add a subtle fade"
Claude: *reads ~/.config/hypr/looknfeel.conf*
*checks Hyprland wiki for current animation syntax*
*edits the file with correct parameters*
*explains what each value does*
Me: *watches my windows smoothly fade in at exactly the speed I wanted*The key part: Claude checked the wiki first. Because the skill explicitly says "DO NOT rely on cached or memorized window rule syntax. The format has changed multiple times." It knows its own limitations.
Dynamic workspaces that just work
Here's one that solved an annoyance I'd been ignoring for months. My laptop moves between desk (with external ultrawide) and couch (laptop only). I wanted workspaces to automatically distribute between monitors when docked, and collapse to just the laptop screen when mobile.
# ~/.config/hypr/monitors.conf
monitor = eDP-1,1920x1080@60,0x0,1
monitor = desc:HP Inc. HP Z38c,3840x1600@60,1920x0,1
# Laptop (internal display)
workspace = 1, monitor:eDP-1, default:true
workspace = 2, monitor:eDP-1
# External monitor (HP Z38c - matches regardless of DP port)
workspace = 3, monitor:desc:HP Inc. HP Z38c, default:true
workspace = 4, monitor:desc:HP Inc. HP Z38c
workspace = 5, monitor:desc:HP Inc. HP Z38c
workspace = 6, monitor:desc:HP Inc. HP Z38cThe clever part: using desc: instead of the port name like DP-1. See, my Lenovo Thunderbolt dock has a... complicated relationship with Linux. The display port would randomly change between boots. Sometimes DP-4. Sometimes DP-5. Once it was DP-7 for reasons I'll never understand. Every time it changed, my workspace config broke.
Claude's solution: forget the port entirely. Match by monitor description instead, which never changes. It figured this out by reading the Hyprland docs and checking my actual monitor output with hyprctl monitors.
Now when I unplug from the dock, workspaces 3-6 gracefully fall back to the laptop screen. When I plug in, they automatically jump to the ultrawide. No manual switching. No scripts. Just config that works.
Tweaking without breaking
The thing about Hyprland configs is that they're incredibly powerful and also incredibly easy to mess up. I wanted smaller gaps between windows, slightly more blur on transparent elements, and a waybar that showed less information.
Old me would have spent an hour in config files, breaking things, reverting, trying again. New me:
Me: "Make the gaps between windows smaller, add more blur to
the waybar, and hide the workspace indicator when I only
have one workspace active"
Claude: *reads ~/.config/hypr/looknfeel.conf*
*reads ~/.config/waybar/config.jsonc and style.css*
*makes targeted edits*
*runs omarchy-restart-waybar*
"Done. Gaps are now 4px instead of 8px, blur increased
to 12 passes, and workspace indicator auto-hides."Three config files, six changes, zero time spent reading documentation. And because Claude reads the existing values first, it makes incremental adjustments rather than overwriting everything with defaults.
145 commands I don't need to memorize
Omarchy has ~145 commands following the omarchy-<category>-<action> pattern. The skill teaches Claude how to discover them:
# Find all omarchy commands
compgen -c | grep -E '^omarchy-' | sort -u
# Find commands by category
compgen -c | grep -E '^omarchy-theme'
compgen -c | grep -E '^omarchy-restart'
# Read a command's source to understand it
cat $(which omarchy-theme-set)So when I ask "how do I change my wallpaper?", Claude doesn't guess. It looks up the actual commands, reads their source code, and gives me the exact invocation. No more Stack Overflow. No more outdated forum posts. Just the actual answer from the actual source.
The trust equation
"But wait," you're thinking, "you gave an AI access to system files? Isn't that terrifying?"
Yes. It absolutely can be. There are reports of Claude constructing poorly thought-out rm -rf commands that wiped entire volumes. One wrong variable expansion and suddenly your home directory is gone. This is real and it happens.
Which is why I never, ever run Claude Code with --dangerously-skip-permissions when working with system files. That flag exists for automated pipelines where you've already validated everything. It does not exist for "let's see what happens when I ask Claude to clean up my disk."
Every command Claude wants to run shows up in my terminal first. Every file edit appears in a diff. I read them. Sometimes I reject them. Sometimes I ask "wait, why are you deleting that?" and Claude explains its reasoning, and sometimes that reasoning is wrong.
The AI proposes. I approve. That's the only way this works safely.
What I'm not doing
For the sake of honesty: I'm not letting Claude touch everything. SSH keys? No. Passwords? Absolutely not. Production server configs? Not without careful review. The trust I've built is for my local development environment, not critical infrastructure.
Also, I still learn things myself. When Claude optimizes something, I read the changes. When it suggests a command, I make sure to understand what it does before running it. The goal isn't to outsource all system knowledge - it's to have a really good teacher who can show me things I didn't know existed.
Try it yourself
You don't need Omarchy to start. Ask Claude Code to audit your .bashrc. Have it check your pacman or apt configuration. Let it suggest optimizations and review them carefully before applying.
If you want to go deeper, look into Claude Code skills. A skill is basically a document that teaches Claude about your specific environment - where configs live, what commands exist, what's safe to touch. Claude becomes exponentially more useful when it actually understands your setup.
And if you're curious about Arch but intimidated by the setup process: Omarchy is how I got here. It's opinionated, beautiful, and ships with a Claude skill out of the box. Not a bad place to start.
The worst that happens is you learn something about your own system. The best that happens is you spend less time fighting configs and more time actually using your computer.
And your progress bars turn into Pac-Man. Which, honestly, might be the best part.
Everything described here uses Claude Code's standard file access capabilities. Your mileage may vary. Side effects may include finally understanding what your .bashrc actually does.