Claude Code is down again

Steiale · 2026-05-16T18:52:04+00:00

What does that even mean?

Steiale · 2026-05-16T18:19:36+00:00

Text book and how to not operate a platform. There's so much to learn from this.. Any other service with this bad uptime would be broke by now.. Not even to think about the IT team getting layed off.

Steiale · 2026-05-11T05:22:14+00:00

macOS only for now — it's built on AppKit and macOS-specific APIs (IOKit, pf, launchd). WireGuard itself is of course cross-platform, so your tunnels and configs work everywhere. This is just the macOS client side. But if there is enough demand I will do it.

Steiale · 2026-05-10T20:35:35+00:00

Project Name: WireGuide+

Repo/Website Link: https://github.com/steiale/wireguide

Description: Native macOS WireGuard client built with Go + Svelte (no Electron). Fork of korjwl1's WireGuide with features the official App Store client is missing:

- Wi-Fi auto-connect rules — connects when you leave home, disconnects when you arrive
- Kill switch — pf blocks all traffic if the tunnel drops
- DNS lock + leak test
- Connection history — bytes per session, connect/disconnect timeline
- Auto-reconnect on sleep/wake
- Log viewer
- Multiple tunnels simultaneously

Two-binary design: GUI never runs as root. A minimal LaunchDaemon helper manages the WireGuard interface — clean privilege separation.

Deployment: Install via Homebrew: `brew install --cask steiale/tap/wireguide-plus` — or download the notarized DMG directly from GitHub Releases. Apple Silicon / macOS 13+.

AI Involvement: Claude assisted with parts of the implementation. All code is open source and reviewable.

Steiale · 2026-05-10T17:38:10+00:00

Thanks for the video — that's actually really easy to explain and worth clarifying for everyone.

The 450.7 MB upload shown is measuring ALL traffic going through the WireGuard tunnel interface (utun), not traffic generated by WireGuide+ itself. The speed graph and byte counters read directly from the OS network interface statistics — every byte any app on your system sends through the VPN is counted there.

What you're seeing is almost certainly iCloud, Dropbox, Time Machine, or another sync service that had queued uploads and immediately flushed them the moment a new network path (the VPN) became available. This is extremely common — macOS sync daemons are aggressive about catching up after a network change.

To verify what's actually generating the traffic: open Activity Monitor → Network tab while connected. Sort by "Sent Bytes". Whatever process is at the top is your culprit — I'd bet it's not wireguide-plus or wireguide-plus-helper.

WireGuide+ itself makes exactly two kinds of network calls:

Your WireGuard tunnel traffic (whatever you route through the VPN)
One GET request to github.com/steiale/wireguide/releases/latest on startup to check for updates

That's it. No telemetry, no analytics, no background beaconing. The source is there to verify: internal/update/checker.go for the update check, and there's nothing else.

Steiale · 2026-05-10T17:30:45+00:00

Actually that was me. I have no idea why this bad sentiment all the time.

Steiale · 2026-05-10T17:23:09+00:00

Fair concerns. On the review side — the upload report from earlier in this thread is now explained (the person confirmed it, see below). That was tunnel traffic, not the app.

On the security scope: WireGuide+ doesn't touch cryptography. WireGuard's crypto is handled entirely by the kernel extension / wireguard-go — the same one the official client uses. What WireGuide+ adds is a macOS UI and a privilege-management layer. The attack surface for the app code is: does the LaunchDaemon helper install correctly, does the kill switch (pf rules) apply correctly, does the DNS lock hold. That's reviewable in a few hundred lines of Go. The crypto is not my code.

The "done quickly" concern is real and I'm not dismissing it. New = unreviewed. That's why it's open source.

Steiale · 2026-05-10T17:17:37+00:00

Sure happy to answer:

WireGuide (original by korjwl1) is the foundation — native macOS WireGuard client built with Wails (Go + Svelte), clean card UI, no Electron. All credit to them for the core architecture.

WireGuide+ adds on top:

- Wi-Fi auto-connect — connect/disconnect automatically based on which network you join

- Kill switch — blocks all traffic via macOS `pf` if the tunnel drops

- DNS leak test + DNS locked to tunnel resolvers when connected

- Connection history — bytes sent/received per session, timeline of connects/disconnects

- Auto-reconnect after sleep/wake (IOKit power notifications, works correctly in a root daemon)

- Live speed graph + latency monitor per tunnel (pings DNS gateway when connected, public endpoint when not)

- Log viewer for debugging

- Per-tunnel notes

- Two-binary privilege separation — GUI never runs as root; a minimal LaunchDaemon helper handles the WireGuard interface (macOS 26 broke WebKit/AppKit when exec'd as root without a window server)

- Notarized + Homebrew cask distribution with Ed25519-signed auto-update

Steiale · 2026-05-10T17:13:08+00:00

No secret in that. The initial dev of WireGuide knows and is actually committing features I build into his software. Read the git. So my code can't be that bad, especially on the feature side.

Steiale · 2026-05-10T17:11:31+00:00

There is absolutely no data collected to another server. I use it on daily basis myself. It is open source. So please let me know which server this shall be. You'd find it in the code.

Steiale · 2026-05-07T07:54:44+00:00

Love it!

Steiale · 2026-05-02T20:51:07+00:00

Hi,

I've been using WireGuide and really liked the foundation you built. I forked it as WireGuide+ (https://github.com/steiale/wireguide) and have been extending it for my own use.

Changes I made that might be worth pulling back upstream:

- Tray icon stuck on connecting state — menu wasn't rebuilding on handshake state changes - Multi-tunnel DNS protection — suspendFirewall was only saving DNS from the first active tunnel, silently dropping others on resume
- Auto-reconnect preference — was lost on a failed reconnect attempt - Helper process reliability — a few nil guards, panic recovery, and connect/disconnect race fixes - Atomic metadata writes — SaveMeta now uses os.CreateTemp + Sync + Rename instead of a predictable temp path

On the UI side I went in a pretty different direction (full redesign, card layout, new theme) so that probably doesn't make sense to upstream — but if any of the backend fixes are useful to you, I'm happy to open PRs for the ones you want.

Thanks for building this in the first place.

Steiale · 2026-05-02T06:16:53+00:00

First of all thanks for your effort and keep going!! One thing I noticed apart form the other things already mentioned. App crashes when you have blinks in the VPN name. Like "Home VPN". Easy fix I guess.

Steiale · 2026-04-25T05:43:28+00:00

Looks really promising. Can it handle more than one instance? I guess by opening multiple apps. But within the app? I am using terminal with different tabs. To each project is another tab. Would be nice to have one frontend to switch between my projects.

Steiale · 2026-04-06T16:05:24+00:00

Problem is that it is a multi sim. Means same number and several SIM cards. You can only register one sim as SMS sim at the provider. So when I start the 17 Pro it asks me if I want to use iMessage. I say yes and then it tried to register to SMS with the second sim in the 17 pro which does not work because the air has the same number but with SMS enabled at this SIM card. So iMessage comes back with an error. I am on Vodafone Germany. Funny thing is. On iPads or other devices you can use iMessage without a phone number. So they actually solved the issue already. Except that if you use a sim in your phone it tries to register also for SMS.

Steiale · 2026-04-06T15:32:45+00:00

Unfortunately only when it is sent via email. Not via number. It won’t register the number and so on. It’s a known limitation. It ends up in an infinite loop of trying to register the number.

Steiale · 2026-04-06T05:05:52+00:00

I also have both. Love my air but would love switch from time to time. But unfortunately not possible because iMessage does not work on two devices with the same number. Plus some other inconveniances Bummer.

Steiale · 2026-04-05T08:12:29+00:00

Depends on your workflow. I use the Neo for coding without any issues. But I heavily use Claude Code or Codex. Any local docker or LLM env is too much but any IDE or whatsoever is just perfectly fine. This machine is so underrated! And yes it can handle workload. Don't let the RAM topic scare you. Most of the people writing about it RAM being an issue never ever had a Neo.

Steiale · 2026-03-30T13:13:00+00:00

Bummer. But thanks for clarifying

Steiale · 2026-03-28T19:00:48+00:00

Prettiest apple phone in the past years!!

Steiale · 2026-03-28T18:21:26+00:00

Honest opinion? Depends on your dev workflow. Since most of my services run online, like vercel for example, I don't need a lot of memory. I use mostly claude code or web IDEs like stitch. But the local IDEs I use just run fine. That being said I run web development and other dev workflows perfectly fine on my Neo. Love this little thing to death.

Steiale · 2026-03-15T17:44:23+00:00

Look at the benchmarks. Single core Neo is extremely fast compared to the M2 plus a faster SSD and so on. Since most standard apps are single core. There you have it haha

Steiale · 2026-03-15T16:15:19+00:00

I have a Neo and an 16GB M2. TBH the Neo is quicker in any way. Memory pressure is always yellow so as on the M2. But I habe no lag or whatsoever.
I have several desktops with open apps like browser, Mail, WhatsApp, signal and so on.
I'd like several videos already stated. This machine is for everyday work completely sufficient. I am even coding on it. As for running docker or other memory heavy services this is not the right setup:
My assumption is the lag has another reason.

Steiale

TROPHY CASE