I Moved From MacOS to Linux

Motivation for switching to Linux (2026)

The speaker moved most development off a MacBook and onto a Linux desktop to better support agent-heavy workflows and avoid macOS overhead.

Hardware choice (Framework desktop, refurbished)

• Purchased a refurbished Framework desktop that arrived in perfect condition.
• Noted missing components (at the time described):
  • No CPU fan
  • No NVMe drive
• Configured with:
  • 64GB RAM
  • A Ryzen processor with AI support
• Performance assessment:
  • “incredible,” handling “any job” with practically no problems

Physical + device networking setup (home server model)

The Framework Linux machine is used as a home server, not an always-directly-used desktop.

Connections described:

• Plugged into a network switch
• Uses HDMI + USB-C for two GL.iNet KVM switches
• The KVMs provide remote desktop-like access through a browser (locally or remotely).

Tailscale integration

Remote access works because the KVM is reachable within a Tailnet (Tailscale network).

Core remote-access foundation: Tailscale

Tailscale is positioned as the “foundation” for the system.

Use case:

• Connect devices into a pseudo-LAN so the MacBook and Linux machines can communicate as if they are on the same local network.

What it enables for practical dev ops:

• SSH
• rsync
• agents connecting to machines
• accessing web services (e.g., opening a site from the dev server)

Agent workflow / orchestration approach (Codex + agents)

Most configuration and changes are handled by agents rather than manual administration.

Setup pattern for new devices

• Open CodeX on machines
• Instruct agents to enable SSH between machines

Verification emphasis

• The speaker stresses watching how agents set up skills and ensuring correct behavior.
• Don’t let agents blindly build everything.

Custom “skills” and device knowledge base

The system uses a private configuration project defining agent skills.

Key artifact: devices.md

devices.md contains a list of Tailnet devices with details such as:

• device names
• Tailscale domains
• destination
• LAN IP + Tailscale IP

Benefit:

• The system can automatically know how to connect/transfer to specific devices without repeatedly re-explaining details.

It also loads tmux configuration for remote sessions.

Remote terminal UX via tmux

When SSH’ing, tmux auto-opens a session:

• named with device name/date
• with visual indicators

Additional UX details:

• Color coding indicates which device/agent is involved (e.g., Hermes agent highlighted differently).
• Key persistence benefit:
  • If the user starts work (e.g., via Claude) and disconnects, the process can continue on the remote machine because tmux keeps it running.

Overall framing:

• It becomes a 24/7 private dedicated instance running tasks.

Sponsor alternative: Cursor cloud agents

Cursor is presented as a way to avoid heavy home-server orchestration when a simpler setup is desired.

Key claims

• Cursor cloud threads create an independent copy of the working tree each time.
• Parallelization: spawn multiple threads without hardware limits.
• Fast startup: cited as <300 ms.
• Live access:
  • real-time desktop view
  • browser access to the cloud environment
• Automatic port forwarding:
  • preview a site via localhost (example: localhost:5173), even though it runs in the cloud

Changes can be pushed/applied from:

• desktop app
• mobile app
• Grokbot (mentioned as a place to push changes)

Practical “real work” workflow

The speaker uses Codex/Claude mainly to send tasks to the right machine.

Thread/job management idea

• If something runs too long, the agent can move or resume work elsewhere.
• Later, the user can ask the same thread for status updates.

Example: T3Code

• Web access to a remote instance through a URL tied to Tailscale.
• Avoids relying on desktop apps; browser-based workflow works home and away.

For diffs/dev servers:

• The agent downloads the latest changes and launches a web interface/dev preview
• The user can view results remotely via a Tailscale link

Why Linux helps vs macOS for agent loads

• macOS monitoring/protection overhead can increase CPU usage when many agents run.
• Linux is described as more efficient:
  • processes “just work,” causing less unwanted CPU time.

Evidence cited:

• A btop screenshot shows many long-running agent tasks concurrently (30–40 agents claimed) with minimal perceived resource impact.

Tradeoffs of distributed/remote dev

Context loss

• Moving work can cause loss of context:
  • files
  • project state
  • scattered file locations
• Agents can mitigate by transferring required files, but orchestration is still needed.

Environment synchronization

• .env files may need copying.
• The speaker sometimes automates this with an agent.

Secrets management upgrade

• Switched to Infisical for centralized secrets so each machine only needs login once.

Apple/macOS limitations and workaround

Remote Linux dev sacrifices access to macOS-native tooling (e.g., Xcode/iOS/macOS-specific features).

Suggested alternative:

• remote access to a Mac mini if necessary

Most work remains on Linux unless Apple-specific development is required.

Main speaker “sources” (as referenced in the subtitle flow)

• Main speaker: the video’s author/host (unnamed in subtitles)

Tools/companies/products mentioned:

• Tailscale
• GL.iNet (KVM switches)
• CodeX (agent tooling)
• Claude (agent/task interface)
• Cursor (Cursor cloud agents)
• T3Code
• Infisical (secrets management)
• Grokbot
• tmux (session management)
• Hardware/OS: Framework, Ryzen, macOS, Linux