Set up your admin computer

TL;DR: Set up an always-on admin computer where you and your AI operator can configure and troubleshoot the rest of your system. Create separate accounts, keep a working clone of your private GitHub repository, and test access and recovery.

Your admin computer is where you and your AI operator work together to configure, maintain, and troubleshoot your home services. Keeping it on means you can close your laptop without ending a job and resume from another device.

This guide uses a Mac mini in that role and walks through its macOS setup. A dedicated always-on Linux or Windows PC can fill the same role; the concepts still apply, but the setup instructions differ.

You can use an AI operator on your current computer to help prepare these steps. It can explain choices and generate the instructions before it has access to the new admin computer.

What you'll set up#

Create a standard macOS account, such as operator-observer, for the AI operator. Keep your own administrator account for installing software, changing access, and recovery. Don't sign the AI operator's account into your personal password manager or give it your home folder as its workspace.

The separate account protects files that macOS denies it permission to read. It doesn't prevent every network connection: both accounts use your admin computer's network. Your router and other computers still need their own access controls. If you need to stop the AI operator from reaching particular devices at all, ask for an isolated virtual machine or separate device and a test of that restriction.

Connect your admin computer by Ethernet if possible. Set it to remain awake for the work you need, and leave enough free storage for logs and temporary files. The display can sleep without stopping the computer. Apple documents energy settings, Remote Login, and Screen Sharing; have the AI operator check the instructions for your macOS version.

Preserve two ways in#

The AI operator's app may offer convenient remote control from your phone or laptop. Set up a separate way to operate your admin computer itself as well: Screen Sharing for its desktop, or SSH for its command line.

At home, these should work through your admin computer's local address without the AI operator's app. Away from home, use your private remote-access VPN. The network chapter sets that up. Don't open Screen Sharing or SSH directly to the public internet to make this step easier.

Optional console access with PiKVM#

Screen Sharing and SSH depend on macOS being far enough through startup to run them. PiKVM is a separate device that lets you see the computer's video output and operate its keyboard through a browser. Include your admin computer in this plan, so you can troubleshoot the machine where your AI operator normally runs.

For an admin computer and one server, use either one PiKVM per computer or a single PiKVM with a compatible KVM switch. For more than two computers total, use a switched setup. The PiKVM section in Server setup explains the connections, power arrangements, private remote access, and tests.

Test remote control before depending on it#

Enable only the users you intend to allow. From another computer at home, connect and confirm that you can actually operate your admin computer. Close the AI operator's app and repeat the test.

If you enable a provider's remote-control feature, protect that account with a passkey or multi-factor authentication. Save its recovery codes in your password manager and make sure you can recover that password manager without your admin computer. Find where to sign out a lost device. Test revocation using a spare session so you know it really stops access.

Don't leave an administrator terminal or an unlocked password manager visible in the AI operator's desktop. Remote control of that desktop can expose whatever is open in it.

Before installing your AI operator#

First establish your own login and access from another local computer. Create the AI operator's standard account, its working folder, and a backup destination. Decide which provider may receive the information in that folder.

You can then ask the AI operator to prepare the remaining setup as a single procedure. It should explain the screens you'll use, what needs administrator approval, and how you'll check the result. You should not have to invent a backup system or understand every access setting before it tells you where to start.

Prompt to paste:

Help me set up this Mac mini as my always-on admin computer. First identify
its macOS version and the accounts and remote-access methods already in use.
Prepare instructions for a separate standard operator account, a limited
workspace, local recovery, and backup of the setup notes. Explain each choice
to me, including what information the model provider could receive.

Don't change my personal account or weaken disk encryption. Prepare any
administrator changes together, with checks and recovery instructions. Use
the current Apple and client documentation for settings. Keep the
AI operator's account separate from my credentials and private archive.

Keep disk encryption unless you accept the recovery tradeoff#

FileVault protects your admin computer's stored data if someone steals it. Keep it enabled unless you've deliberately decided otherwise. A fully powered-off Mac may need someone to unlock it before remote tools work; the behavior depends on the hardware and macOS version.

Save the recovery key in your password manager and keep the password manager's recovery method somewhere independent of your admin computer. Then test an ordinary restart and a full shutdown followed by power-on. Write down when a local login is required. If someone must be there to unlock it after a power failure, that's a practical limit to plan around.

Grant macOS privacy permissions deliberately#

An app may ask for access to the screen, other applications, or files. These permissions do different things. Screen Recording can expose everything visible on the desktop. Accessibility can let an app operate controls. Full Disk Access broadens which files it can read.

Ask what task requires each permission before enabling it. Try the narrower setup first, and record the permission in your notes with the app's name and its purpose. Recheck after updates if the app begins prompting again. Don't respond by granting access to every application.

Remove prompts that would stop unattended work#

A scheduled job cannot answer a password-manager dialog while you're away. Give that job its own limited credential rather than leaving your vault open.

Here is where the important credentials belong at the start:

The notes should identify entries by name, such as “Home server backup recovery,” and say which job uses them. Don't copy the secret values into the notes or chat.

The limits of file permissions#

A private file in the AI operator's account can still be read by processes running as that account. That is why its server key must grant limited access on the server. Hiding a powerful key in a different subfolder does not make it safe.

If the AI operator later gains deployment access, keep those credentials separate from general web research. You may need another account or isolated environment. Start with observation; you don't need to solve every future automation requirement today.

Create a private operations repository#

Create a private GitHub repository for the homelab, then clone it into an ops folder in the AI operator's Mac account. GitHub holds the shared repository and its history. The Mac holds the working copy where you and the AI operator read and edit files.

Put the setup records in that repository, including the equipment list. “Inventory” just means the record of what equipment, disks, addresses, and software you have; it isn't a separate storage system.

For each completed task, have the AI operator show the changes, make a Git commit with a useful description, and push it to GitHub. A commit records a version; push sends that version to GitHub. A file saved on your admin computer but never committed has no Git history. A commit that hasn't been pushed is still only local.

This includes records, not just scripts. If you replace a disk, change an address, revise a recovery procedure, or discover why a previous fix failed, that belongs in the versioned history. For unfinished work, save a clearly labeled checkpoint that says what is proposed and what has actually been applied.

To revisit a change, ask the AI operator to compare the relevant commits. It can prepare an older working configuration or a corrected new version. Changing a file in Git doesn't automatically change a running service: the AI operator must apply the chosen configuration and test it. Git also cannot restore a deleted photo or undo a database migration by itself; those need the backups described later.

Keep a current local copy of the recovery instructions so a GitHub or internet outage doesn't block access. Passwords, private keys, recovery codes, and sensitive raw session exports stay outside the repository. Commit references to their locations and sanitized summaries instead.

Prompt to paste:

Create a private GitHub repository for this homelab and a local working copy
named ops on my admin computer. Put configuration, equipment records, decisions,
maintenance procedures, change records, and session summaries under Git.
Don't commit secrets or sensitive raw transcripts; record safe references.

At the end of each task, review the diff, check for secrets, commit the work
with a meaningful message, and push it. Report the commit and push result.
For unfinished work, distinguish proposals from changes already applied.
Keep recovery instructions available offline. When recovering an older
version, explain how to apply and test it; don't imply that reverting Git
also restores application data or changes the live system.

Keep complete session and system-administration records#

Save full session exports and command output in a separate private archive under your own account. They can contain details that don't belong in every future AI operator session. Give the AI operator a short index containing the date, task, outcome, and archive filename.

Choose a backup destination for that archive and write down how to recover its encryption key without your admin computer. Test this by opening one backed-up record from another device. Keep the decryption step out of the AI operator's screen or transcript capture if it would reveal the key.

Also try a fresh AI operator session: ask it to find a decision in the sanitized notes and explain what happened. If a fact is only in the private archive, you can supply the relevant excerpt after checking it. Old records explain the history; the AI operator must still check whether the computer has changed since then.

Install and test one coding AI operator#

Use a client you already know, installed from its official source in the standard account. Start with one client. You can add an independent reviewer when a task needs one.

Open ops as its workspace, rather than your whole home directory. Check its file access, shell access, network access, and data-sharing settings. A client running on your Mac may still send selected files and command output to its AI provider.

Begin with the client's restricted permission mode. Run the small AI operator test, then choose a less interruptive approval mode only if it preserves the restrictions you've tested. Permission-mode names change; ask the AI operator to use the client's current official documentation. Fewer confirmation dialogs do not by themselves make access safer.

To check session persistence, start a small task, disconnect the viewing laptop, then reconnect. For command-line sessions, the AI operator can set up tmux, which keeps a terminal session running after a connection closes. A desktop app may handle this differently. Test the app you actually use, including whether it needs you to sign in after a Mac restart.

Prompt to paste for the first local task:

Work only in this ops folder. Check the local facts I've authorized and update
our equipment and setup notes. Don't request administrator access, my SSH
key, my password manager, or access to the private session archive. No server
is authorized until I identify it and its permitted account.

Tell me what you checked, what remains unknown, and where you saved the notes.
If I need to act, give one complete NEXT ACTION naming the computer, account,
and steps. Otherwise say no action is needed.

Give the AI operator read-only access to the first server#

Do this after you've installed the Linux server and tested your own login. The AI operator uses a separate server account and a dedicated SSH key. You install its public key; your administrator key stays in your account.

Ask it to demonstrate what that account can and cannot do. An unrestricted shell under a standard user is limited, but it can still modify that user's files. A purpose-built read-only status command can restrict it further. Either way, it should not be able to install software, alter system configuration, read your secrets, or control Docker just to collect status.

The Server setup covers the setup and tests. If you haven't built that server yet, note this step as pending.

How every configuration change runs#

For changes requiring your administrator account, the AI operator prepares and checks the proposed files before asking you to run anything. It should save the current working files in a named, dated location and give you a recovery procedure for them.

You review what the change means, then run the complete prepared procedure. It should verify the target, apply the reviewed configuration, and check the result. The AI operator checks from its limited account as well. If anything fails, it explains the failure and recovery options rather than continuing with improvised edits.

Use the configuration-change prompt when the AI operator needs the precise preparation and installation requirements.

Practice connecting when something fails#

Connect without internet access or DNS#

Choose a time when the household can tolerate a brief interruption. Have the current network settings and restore instructions available on paper or another device before disconnecting anything.

Without relying on internet access or name lookup, use the recorded local IP address to reach your admin computer. Confirm that your local login works and that you can restore the network service you stopped. Test any existing server the same way. Don't stop the whole network merely to test a server you haven't built yet.

Test remote access away from home#

If you already have a VPN, turn off Wi-Fi on your phone and connect through cellular data. Open a fresh remote session to your admin computer. Close the AI operator's remote-control feature and check that your independent access still works.

If you don't have a VPN yet, leave this check for the network chapter. The essential check now is your independent local access.

Before moving on#

Before moving on, check that you can sign in locally, reach your admin computer from another computer at home, and explain its restart and unlock behavior. Confirm that the AI operator works in its own account and cannot read your private account or use administrator privileges.

Finally, open the backed-up setup notes from another device and resume a task from a fresh AI operator session. You now have somewhere stable to run the AI operator and a record you can recover if that Mac fails.