Setting Up Claude Code and ChatGPT Codex on a Linux Server: Step by Step

This guide takes you from a freshly installed Debian or Ubuntu server to a working AI agent that analyzes logs, checks configurations and carries out maintenance tasks. We set up Claude Code (Anthropic) and Codex CLI (OpenAI, the command-line tool behind ChatGPT), both under a dedicated user with limited permissions, and show Gemini CLI (Google) as a third option. All commands were tested on a KernelHost KVM root server running Debian 13 and Ubuntu 24.04. The article AI Managed Server: connecting AI agents securely explains what an AI managed server is in principle and which architectures are available.

Current as of September 2026. The tools evolve quickly; if in doubt, check the flags with claude --help, codex --help or gemini --help.

Prerequisites

• A root server with Debian 12 or 13 or Ubuntu 22.04 or 24.04 and root access via SSH. On AlmaLinux and Rocky Linux the steps are the same; only the package commands use dnf instead of apt.
• Basic hardening in place: SSH login with a key, a firewall, automatic security updates. The checklist for new root servers covers all of this.
• An Anthropic account (Claude Pro, Max or Team) or an API key, plus a ChatGPT account (Plus, Pro or Team) or an OpenAI API key. If you only want to set up one tool, you only need one of these.
• Outbound HTTPS to api.anthropic.com and api.openai.com. KernelHost servers allow this out of the box; if you run a restrictive firewall of your own, it has to permit this traffic.

How much server does an AI agent need?

An AI agent needs no special hardware and no GPU on the server, because the language model runs at the provider. The server only runs the command-line tool and Node.js, which together usually take up a few hundred megabytes of memory during a session. On a server with little else running, 2 vCPUs and 4 GB of RAM are enough. If the server also hosts websites, databases or game servers, plan for about 1 GB of memory headroom for the agent. A KernelHost KVM root server is provisioned in about 30 seconds and billed PrePaid with no minimum term, which also makes it a good test system for trying out the agent first.

Step 1: Create a dedicated user and limit sudo

The agent never runs as root. It gets its own account and, through a sudo allowlist, exactly the commands it needs. Start with a few read-only commands and extend the list when a task really requires it.

sudo adduser --disabled-password --gecos "KI-Agent" aiagent
sudo tee /etc/sudoers.d/aiagent >/dev/null <<'EOF'
aiagent ALL=(root) NOPASSWD: /usr/bin/journalctl *, /usr/bin/systemctl status *, /usr/bin/systemctl restart nginx, /usr/bin/apt-get update, /usr/bin/apt-get upgrade -y, /usr/bin/tail *, /usr/bin/df *, /usr/bin/ss *
EOF
sudo chmod 440 /etc/sudoers.d/aiagent
sudo visudo -cf /etc/sudoers.d/aiagent

The last line checks the syntax. A mistake in a sudoers file can lock everyone out of sudo, so this check is always part of the process. --disabled-password ensures that nobody can log in as aiagent with a password; you switch to the account later with sudo -iu aiagent. The article Creating a sudo user on Linux explains how sudo users work in general.

Targeted write permissions instead of an editor via sudo

If the agent needs to change files in /etc, do not allow it to run nano via sudo (that would let it edit any file, including /etc/sudoers). Instead, work with a group and targeted write permissions, for example setfacl -m u:aiagent:rw /etc/nginx/sites-available/meine-seite.conf. To begin with, it is perfectly fine if the agent proposes changes and you apply them yourself.

The same applies to commands with wildcards in the allowlist. /usr/bin/tail * lets the agent read any file that root has access to, including files that contain credentials. If you do not want that, spell out the allowed paths, for example /usr/bin/tail -n 200 /var/log/nginx/error.log.

Step 2: Install Node.js 22

Both tools run on Node.js. Claude Code requires at least version 18 and Codex CLI at least version 22, so we install 22 LTS. The Debian 12 package sources ship a version that is too old; NodeSource provides the current one:

curl -fsSL https://deb.nodesource.com/setup_22.x | sudo -E bash -
sudo apt-get install -y nodejs
node --version
npm --version

Alternative without root privileges: nvm

If you would rather not run scripts from the internet with root privileges, use nvm in the agent user's home directory; that way, no root privileges are needed at all. Take the nvm install command from the project's README; after that, three lines are all you need:

nvm install 22
nvm alias default 22
node --version

Details and other methods are covered in the guide to installing Node.js on Debian.

Step 3: Install Claude Code and sign in

From here on, we work in the agent's account:

sudo -iu aiagent
curl -fsSL https://claude.ai/install.sh | bash
claude --version

The native installer places Claude Code in ~/.local/bin, and Claude Code then keeps itself up to date. Alternatively, you can install it via npm with npm install -g @anthropic-ai/claude-code; if that fails with EACCES, see the troubleshooting section below.

Signing in on a server without a browser

The first time you start claude, the tool asks you to sign in. With a Claude account, it normally opens a browser; on a server without a browser, it shows a URL and a code that you confirm on your laptop or smartphone. From then on, the sign-in applies to this user on this server until you sign out.

API key for scripts and cron jobs

For scripts and cron jobs, an API key is the better choice:

echo 'export ANTHROPIC_API_KEY="sk-ant-..."' >> ~/.bashrc
chmod 600 ~/.bashrc
source ~/.bashrc
claude -p "Reply with OK only" 

This way, the key only lives in the agent user's home directory, which other users cannot read. Create it in the Anthropic console with a monthly spending limit, so that a session that gets out of hand cannot become expensive. Never put the key itself into a task for the agent or into a file the agent is supposed to output.

Step 4: Configure Claude Code for the server

The CLAUDE.md rules file

At startup, Claude Code reads a CLAUDE.md file in the current directory. It contains the rules that apply to every session. Create a working directory with this file in the agent's home directory:

mkdir -p ~/server && cd ~/server
cat > CLAUDE.md <<'EOF'
# Rules for this server
- This is a production server (Debian 13, nginx, PHP-FPM, MariaDB).
- Read-only commands (journalctl, systemctl status, tail, df, ss) are allowed at any time.
- Before any command that writes, briefly explain what it changes and wait for approval.
- Never remove packages, never delete files under /var/lib, never create or delete users.
- Never repeat passwords, keys or customer data in output.
- End every task with a three-sentence summary.
EOF

The file grows over time. Whenever the agent does something differently from how you want it done, add the correction as a new rule. After a few weeks, it reflects the way work is done on your server quite accurately.

The allowlist in settings.json

On top of that comes a tool allowlist, so that Claude Code runs read-only commands without asking and requests approval for everything else. The file ~/.claude/settings.json applies to this user:

mkdir -p ~/.claude
cat > ~/.claude/settings.json <<'EOF'
{
  "permissions": {
    "allow": [
      "Bash(sudo journalctl:*)",
      "Bash(sudo systemctl status:*)",
      "Bash(sudo tail:*)",
      "Bash(df:*)",
      "Bash(free:*)",
      "Bash(ss:*)"
    ],
    "deny": [
      "Bash(rm -rf:*)",
      "Bash(sudo rm:*)",
      "Bash(dd:*)",
      "Bash(mkfs:*)"
    ]
  }
}
EOF

The deny list is an additional safety net, not a wall: a command can be written in many different ways. The real boundary is the sudo allowlist from step 1, because whatever the user is not allowed to do, the agent cannot do either.

The first task, interactively

Now for the first task, run interactively:

cd ~/server && claude
> Summarize the errors from journalctl for the last 24 hours and name the three most common causes.

Unattended as a cron job

And the same task unattended, for example as a daily cron job at 7 a.m. whose result arrives by email:

0 7 * * * cd /home/aiagent/server && /home/aiagent/.local/bin/claude -p "Summarize errors and warnings from journalctl for the last 24 hours. Name the service, the time and the likely cause." --allowedTools "Bash(sudo journalctl:*)" 2>&1 | mail -s "Daily server report" admin@example.com

The -p flag starts Claude Code without an interactive session, and --allowedTools limits the tools to exactly what the run needs. Write actions do not belong in unattended runs. The article Setting up a cron job on Linux covers how to set up cron jobs in general.

Step 5: Install Codex CLI (ChatGPT) and sign in

Installation and sign-in

Codex CLI is OpenAI's tool that brings the models behind ChatGPT to the command line. Install it in the same user account:

npm install -g @openai/codex
codex --version

You sign in with your ChatGPT account (Plus, Pro or Team): start codex, choose “Sign in with ChatGPT” and open the URL shown on a device with a browser. For scripts, set an API key from the OpenAI platform instead:

echo 'export OPENAI_API_KEY="sk-..."' >> ~/.bashrc
source ~/.bashrc

Sandbox and approval mode in config.toml

Codex comes with its own sandbox and an approval mode. Both are set in ~/.codex/config.toml; for a production server, this combination makes sense:

mkdir -p ~/.codex
cat > ~/.codex/config.toml <<'EOF'
approval_policy = "on-request"
sandbox_mode = "workspace-write"
EOF

workspace-write allows writes only in the current working directory, and on-request has the agent ask for permission for anything beyond that. The danger-full-access level removes both restrictions and does not belong on a production system.

Rules in AGENTS.md

Codex reads rules like those in CLAUDE.md from an AGENTS.md file in the working directory; you can use the same content:

cp ~/server/CLAUDE.md ~/server/AGENTS.md
cd ~/server && codex "Check whether all enabled systemd services are running, and list the failed ones with their last error message."

For unattended runs, there is codex exec "Aufgabe", the counterpart to claude -p.

Step 6: Gemini CLI as a third option

Gemini CLI is Google's command-line tool and works on the same principle. It also runs on Node.js and is installed in the same user account:

npm install -g @google/gemini-cli
gemini --version

The first time you start gemini, you sign in with a Google account; for scripts, set an API key in the GEMINI_API_KEY environment variable. Gemini CLI reads its rules from a GEMINI.md file in the working directory, and here, too, you can reuse the content of your CLAUDE.md. Start unattended runs with gemini -p "Aufgabe". Which of the three tools you use is mainly a question of which account you already have: all three work the same way on the server, and you can run several of them side by side.

Alternative: the agent runs on your computer and works over SSH

If you would rather not install anything on the server, start Claude Code or Codex on your laptop and let the agent issue commands over SSH. For this, the server gets a dedicated SSH key for the agent user, and CLAUDE.md contains the rule to prefix all server commands with ssh aiagent@server. This works well for occasional maintenance, but longer tasks and cron jobs run better directly on the server. The field report Connect an AI Agent to Your Server shows in detail what the SSH connection looks like with its own key, a host alias and approvals, and which workflow the agent then follows when it deploys to production systems.

Step 7: Harden and set limits

• A snapshot or backup before every session in which something is going to change. The backup strategy for servers shows how to automate this.
• Keep the approval mode on. --dangerously-skip-permissions in Claude Code and danger-full-access in Codex are meant for throwaway VMs.
• Keep secrets out of reach. The agent user must not be able to read .env files, database passwords or customer data. Whatever it reads is sent to the provider.
• Set a spending limit for every API key in the provider's console.
• Traceability: install etckeeper so that every change under /etc ends up in Git, and keep the agent's summaries.
• Nothing changes for inbound traffic. Both tools only need outbound HTTPS. The firewall, Fail2ban and the host's DDoS protection stay as they are.

The first tasks: five useful assignments

The best first tasks are those that involve a lot of reading and no risk. They quickly show how thorough the agent is and deliver immediate value:

• Log report: “Summarize the errors and warnings from the last 24 hours, grouped by service, with the likely cause.”
• Check services: “List all failed systemd services with their last error message and explain what would need to be done in each case. Do not change anything.”
• Disk space: “Show which directories take up the most space and suggest what can be cleaned up safely.” For background, see the article Disk full on Linux.
• Updates: “Which packages have pending security updates, and which services need to be restarted afterward?”
• Web server: “Check the nginx configuration for errors and outdated settings and explain each finding.”

Only once these results hold up is it worth giving the agent tasks that make changes, and at first only on a test system.

Common errors and solutions

Keeping the tools up to date

Once installed with the native installer, Claude Code updates itself. You can bring the tools installed via npm up to date with a single command:

npm update -g @openai/codex @google/gemini-cli
codex --version
gemini --version

New versions occasionally change flags or default settings. After an update, take a quick look at the release notes before you let unattended runs continue, and check the next daily report for anything unusual.

Conclusion

An AI agent on the server can be set up in an hour: user, sudo allowlist, Node.js, tool, rules. The real work lies in the limits, and here they are deliberately kept tight. Widen them step by step when a task calls for it, never across the board. On a KernelHost root server or dedicated server, there is nothing to unlock for this: root access, a free choice of distribution and outbound connections are standard.

The field report Connect an AI Agent to Your Server describes how an agent then deploys to production systems, with backups, a way back and approvals.

Key takeaways

• Claude Code, Codex CLI and Gemini CLI run on any Linux server with Node.js 22; no GPU is required.
• The agent gets its own user with a sudo allowlist and never runs as root.
• Rules go into CLAUDE.md, AGENTS.md or GEMINI.md, read-only commands go into the allowlist, and everything else needs approval.
• For cron jobs and scripts, an API key with a spending limit is the clean approach, and unattended runs stay read-only.
• A backup before every session, secrets out of reach, approval mode on.
• KernelHost servers come with root access, a free choice of distribution and outbound connections out of the box.