This is how we roll now.
After a bit of tinkering with Zapier and Claude's MCP connectors, I've handed over the keys to my blog to an AI assistant. Claude can now draft, publish, and delete posts on my behalf — all from a simple chat conversation.
Is this the future of blogging? Probably not for everyone. But for a lazy Linux nerd who'd rather be tinkering with something else, it works just fine.
I wanted Claude to manage this blog. Not just draft posts — actually push them. Read files, edit them, commit, done. No copy-pasting, no manual git, no faff. I had no particular plan for how that would work. I just told Claude what I wanted and left Claude to figure it out.
That turns out to be a reasonable way to approach this kind of problem.
Claude.ai supports MCP connectors — a way to give Claude access to external tools and services. Zapier has an MCP endpoint, and Zapier has a GitHub integration. Claude started there.
It mostly worked. Claude could find repositories, read issue and pull request data. Then came the first wall.
Zapier's GitHub integration has a "Create or Update File" action, which sounds right. The problem is that GitHub's API requires a SHA when updating an existing file — a concurrency check. To get the SHA you need to call the Contents API, and Zapier's GitHub integration has no action that does that. It can find repositories, branches, issues. It cannot read a file.
So updating an existing file meant: Claude asks me for the SHA, I run a curl command in the terminal, paste it back into chat, then Claude pushes the update. Every. Single. Time.
curl https://api.github.com/repos/mrgreen3/mrgreen3.github.io/contents/content/links.md \
| python3 -c "import sys,json; print(json.load(sys.stdin)['sha'])"
That is not blog management. That is assisted manual labour.
Claude can fetch URLs, but the claude.ai sandbox blocks api.github.com — the unauthenticated API was rate-limiting from the container's IP almost immediately. Raw GitHub URLs that do work don't return the file SHA anyway.
A personal access token would have solved it, but that means tokens in chat history and things to maintain. Claude kept looking.
Claude.ai supports adding custom MCP servers directly, under Settings → Connectors → Add custom connector. The official GitHub MCP server runs at:
https://api.githubcopilot.com/mcp/
It authenticates via OAuth — connect your GitHub account, done. No tokens, no Zapier middleman, no workarounds.
Once connected, Claude gets proper GitHub tools: get_file_contents (which returns the SHA alongside the content), create_or_update_file, push_files. Everything needed to read a file, modify it, and push the result — without any input from me.
First real test was removing a dead link from the links page. Claude read the file, retrieved the SHA automatically, made the edit, committed. I didn't touch the terminal.
What struck me about this is that I had no idea any of this infrastructure existed. MCP servers, Zapier's GitHub limitations, the official GitHub MCP endpoint — I wouldn't have known where to start. Claude worked through the options methodically: tried Zapier, hit the wall, identified why, looked for alternatives, found the right tool, connected it, and got the job done.
That's the part that's actually useful. Not that Claude can push a markdown file to GitHub — I can do that myself in thirty seconds. It's that Claude can figure out how to do something I didn't know how to set up, try multiple approaches when the first one doesn't work, and arrive at a clean solution without me having to understand the problem space at all.
Claude can now read any file in this repo, edit it, and push the result. New posts, page edits, link updates — all from a chat conversation. The SHA problem is gone because Claude retrieves it as part of reading the file.
The setup is clean. One OAuth connection, no tokens, no workarounds. Claude did the legwork. I made a cup of tea.
There was a final gotcha that nearly didn't make it into this post. Adding the MCP server URL in claude.ai and authenticating via OAuth wasn't quite enough — write access was still being blocked with a 403. The missing step was installing the GitHub App itself on your account, which is separate from the OAuth flow.
Go to https://github.com/settings/installations, find the Claude GitHub MCP Connector, and make sure it's installed on your account with access to the relevant repositories. Without that step the connector can read but not write, and Claude will hit a wall every time it tries to push anything.
Once that's done, everything works as advertised.
FruitBANG is my latest experiment — an ArchBang ISO variant that swaps out labwc for MangoWM.
MangoWM is a Wayland compositor in the dwl lineage — dwl being a Wayland port of dwm. If you know dwm, you already have the mental model: tag-based layout, keyboard-driven, minimal config, no framework overhead. I'd been running it on my desktop for a couple of weeks and liked it enough to want it in an ISO.
ArchBang already does what it does well. Swapping the compositor in place would mean diverging the main build and maintaining something harder to reason about. A fork keeps things clean — FruitBANG is its own thing, built on the same archiso foundation, just with a different compositor and the configs to match.
The stack is the same as my desktop setup:
Boot to a working Wayland session with a tiling window manager that gets out of your way.
It builds. It boots. It works. Whether it's daily-driver ready depends on how much you like figuring things out — the MangoWM ecosystem is smaller than Hyprland or sway, and documentation is thin in places.
ISOs and source are up on the ArchBang site if you want to try it.
Spent most of today getting OctoPrint properly set up and moved off the M710Q onto a Dell Wyse 3040 that's been sitting around doing nothing useful. GreenClaw did most of the heavy lifting.
The M710Q is my main server — it runs indoors. The printer is in the workshop. Running OctoPrint on the server meant a USB cable trailing across the house, which was never a permanent solution. The Wyse 3040 is a tiny fanless machine that can sit next to the printer without me worrying about it.
It was already running Alpine Linux with Docker installed. First job was stripping out Docker — no need for it when OctoPrint is the only thing running. Cleaned up, updated, and moved to a proper pip virtualenv install of OctoPrint 1.11.7.
A few things to sort along the way:
mrgreen user needed adding to the dialout group before OctoPrint could access /dev/ttyUSB0.All fixable. GreenClaw handled it from the server over SSH while I plugged things in at the printer end.
While we were at it, ran through some bed calibration. The Kobra Neo's auto levelling had never been run properly — previous prints were surviving on a Z offset of -1.76 and a prayer. Saved the offset to EEPROM with M851/M500, ran a G28 + G29, and printed a 50x50x2mm test square to verify.
Came out 49x49x2mm — close enough for practical prints, and the 2mm thickness was spot on.
GreenClaw can check printer status, temps, and job progress over Telegram, start and cancel prints, and power the whole thing on and off via the smart plug. First proper test of the full setup and it worked well.
Not bad for a Saturday.
I've been running an AI assistant on my M710Q for a few days now. It's called GreenClaw — I named it, it seemed to appreciate that.
It's built on OpenClaw, which is basically a framework for running a persistent AI agent on your own hardware. Not a chatbot you visit in a browser tab. Something that actually lives on the machine, has access to the filesystem, can run commands, and remembers things between conversations. I talk to it over Telegram.
Practical stuff so far:
pacman -Syu) and rebooted the server on requestIt's not magic. It's a capable model with shell access and some context about my setup. The difference from a chat interface is that it persists — it knows it's running on a Lenovo M710Q, knows the blog workflow, knows the OctoPrint endpoint. It doesn't need re-briefing every session.
The server is a Lenovo ThinkCentre M710Q running Arch. It's a tiny form factor machine — Intel Core i5-7400T (4 cores, up to 3GHz), 16GB RAM, 500GB main SSD and a 240GB NVMe. Low power, quiet, always on. It was already running OctoPrint for the Anycubic Kobra Neo. GreenClaw is just another service on the same box.
I communicate through Telegram. GreenClaw receives messages, does things, replies. It won't take external actions without checking first — no sending emails, no pushing code, nothing public without my sign-off.
I'm not handing it the keys to everything. It has access to what I've given it access to. SSH keys exist, but only for Codeberg. OctoPrint access, but read-heavy. The model is capable of making mistakes and I treat its output accordingly — reviewed before anything goes live.
The blog workflow specifically: it writes, I read, then it publishes. That's the deal.
It's useful in the way a competent person with terminal access is useful — you can delegate things without explaining from scratch every time. Whether that stays true as the setup grows is something I'll find out.
More posts to follow. Some of them will even be written by me.
Thought I would try out a new dynamic window manager called MangoWM.
It's a Wayland compositor — tiling, tag-based, minimal. It sits in the same space as dwl but with a cleaner config format and a few quality-of-life additions that made it worth trying. No GNOME, no KDE, no compositor framework weighing things down. Just a window manager that does what I tell it.
Everything around the compositor is hand-picked:
Everything runs through Super. No Alt conflicts, no guesswork:
Super+Return — foot terminalSuper+Space — wmenu launcherSuper+w — FirefoxSuper+t — TelegramSuper+b — GNOME BoxesSuper+q — kill windowSuper+f — fullscreenSuper+s — floatSuper+1–9 — switch tagsSuper+Shift+1–9 — move window to tagSuper+Shift+arrows — focus directionPrint — full screenshotSuper+Print — region screenshotScreenshots land in ~/Screenshots/ with a timestamp filename and a notify-send confirmation.
The defaults needed work. Animations were the first thing to go — all durations set to zero, layer animations disabled. The compositor feels snappier for it.
Gaps are 3px all round. Focused windows get a soft green border (0x88bb88ff) — just visible enough to know what you're looking at without shouting.
Window rules assign apps to fixed tags automatically: Firefox to tag 3, Telegram to tag 2, GNOME Boxes to tag 4. The workspace is consistent every time.
Tag-based layout suits the way I work. I don't want infinite dynamic workspaces — I want a fixed map I can navigate without thinking. Mango handles that well.
The config format is readable. Changes are fast to test. Compared to the yak-shaving involved in some other compositors, it's been surprisingly low-friction once the initial setup was done.
It's not perfect. The ecosystem is smaller than Hyprland or sway. Documentation is thin in places. But for a personal desktop that I understand top to bottom, it works exactly as intended.
I wanted a systemd-free version of ArchBang. Something minimal, keyboard-driven, and built on Alpine Linux instead. The name—GreenBang—references Alpine's green branding and my own username, and it became the foundation for a distro that strips away the overhead while keeping the philosophy: intentional, lean, dark Wayland desktop with no cruft.
That project is GreenBang, and it's still very much in beta.
Alpine is ruthlessly lean. A base ISO is measured in megabytes, not gigabytes. That's the core philosophy here—do more with less. Wayland felt like the right move because X11 is aging, and if I'm building something new, why carry legacy baggage?
The challenge: Alpine's build system is fundamentally different from anything I'd worked with before. It uses mkimage.sh and overlays, not Arch's airootfs. Two separate files that have to stay in perfect sync: a profile that declares what packages exist on the ISO, and an overlay script that configures what actually loads at boot. Get them out of sync and packages silently fail to install. I learned that the hard way.
Right now, I can boot the ISO into a Wayland session. labwc starts. The user gets created. NetworkManager handles wired and wireless. waybar renders. foot terminal launches. It's functional. Not pretty yet, not complete, but it boots and does things.
That took longer than it should have. Shell sourcing issues, missing dependencies, overlay structure gotchas—Alpine doesn't hold your hand the way some distros do. The documentation is thin. You read C code and source scripts to understand how things work.
Plenty. There are gaps to fill, configurations to polish, and a few things I want that aren't quite there yet. Some will land quickly. Others will take time. I'd rather get it right than rush it out.
This is a side project, not a product. There's no timeline, no roadmap beyond "make it usable." Some days I push a commit. Some days it sits. When I do work on it, I'm usually testing builds in QEMU on a VM, iterating through failed boots and profile tweaks.
I'd be lying if I didn't mention that Claude Code has done most of the heavy lifting—building the profiles, wrangling the overlay scripts, debugging the alpine build system quirks. At first it felt like cheating. But the real work has been mine: understanding what's broken, knowing what the fix should look like, and directing the approach. That's where my Linux experience actually matters. Anyone can run a build. Actually knowing why it failed and what to try next? That part is still all me.
It's therapeutic, honestly. In a world of bloated desktops and frameworks, there's something satisfying about making something minimal that's yours.
GreenBang is very much work in progress. Until then, it's a thing I'm building, learning Alpine's quirks, and slowly moving closer to something I'd actually use as a daily driver.
Linux enthusiast focused on ArchBang, system configuration, and minimal workflows.
This blog documents my experiments, setups, and discoveries as I work with Linux distributions and tools.
Useful resources and links related to Linux, ArchBang, and system administration.
Essential software for Linux workflow:
sway — Tiling Wayland compositor. Minimal, powerful window manager for X11/Wayland.
alacritty — GPU-accelerated terminal emulator. Fast, simple, cross-platform.
neovim — Hyperextensible Vim-based text editor. Modern, scriptable, fast.
fish — User-friendly command line shell. Smart completions and syntax highlighting.
fzf — Fuzzy finder for command line. Search files, history, processes quickly.
Connect with Linux and ArchBang communities:
r/archlinux — Official Arch Linux subreddit. Ask questions, share setups, get help.
r/swaywm — Sway window manager community. Discussion, tips, rice screenshots.
Arch Linux Forums — Official support and discussion forums.
Guides, documentation, and learning materials:
Arch Linux Wiki — Comprehensive documentation for Arch and ArchBang.
Linux from Scratch — Build a Linux system from source. Deep learning resource.
The Linux Foundation — Official Linux news, kernel information, certifications.
Bash Guide for Beginners — Learn shell scripting fundamentals.
Last updated: 2026-05-23
This page is actively maintained. Found a great resource? Open an issue or let me know!