How to Connect Codex to Plesk via SSH: Troubleshooting & Setup Guide

Introduction

Setting up Codex to work directly against a Plesk-hosted site sounds simple on paper: enable SSH, add a key, connect the app and get on with the work. In practice, there are a few moving parts, especially if you want to keep things reasonably locked down.

This guide follows the exact route that worked for us in the end. We used the website's Plesk system user, authenticated with SSH keys, connected through the Codex UI, and installed Codex CLI inside the site user's home directory without giving it sudo.

If you tried the more restrictive chrooted shell first and found yourself going round in circles, don't worry. We did too. The final working setup was a normal /bin/bash shell for the site system user, a dedicated SSH key pair and a local npm-based Codex install for that user only.

What You'll Need Before You Start

Before you begin, make sure you have the following:

• A Plesk-managed website or subscription with access to Hosting settings
• Access to the system user credentials for that site
• The SSH Keys Manager extension installed in Plesk
• A Windows machine with PowerShell and OpenSSH available
• A working Codex desktop app installation (ensure you are using the latest version compatible with your specific server OS).
• Node.js and npm available for the Plesk site user once SSH is enabled

This walkthrough assumes you want Codex to work on a single site using the site's own system user, rather than giving it wider server access.

Why This Route Worked Best

We originally started with /bin/bash (chrooted) because it looked like the safer option. SSH itself worked, but inside the chroot the site user couldn't see node or npm, which meant Codex CLI wasn't straightforward to install.

You can extend the Plesk chroot manually, but for most people that is far more effort than it is worth. The route that got everything working cleanly was:

• use the site's Plesk system user
• enable normal /bin/bash rather than chrooted bash
• use a dedicated SSH key pair
• connect through Codex UI
• install Codex CLI into the user's own home directory, not system-wide

That still keeps the setup reasonably tidy because you are not using root access and you are not handing out sudo.

Step 1: Enable SSH for the Site User in Plesk

In Plesk, open the site you want Codex to work on and go to:

Websites & Domains → your domain → Hosting & DNS → Hosting

Find the SSH access setting and set it to:

/bin/bash

At this point, Plesk is enabling SSH for the website's system user. This is important: we are not creating a full new Linux user here and we are not giving Codex a Plesk admin account. We are simply allowing SSH for that site's existing system user.

If you see the chrooted option, remember that the non-chrooted /bin/bash route was the one that worked cleanly for Codex in our setup.

Step 2: Add the Public Key in Plesk

Install and enable the SSH Keys Manager extension in Plesk if you haven't already. After that, find the SSH Keys area for the site or subscription. Depending on your Plesk view, this can be tucked away in the side panel or subscription-level options.

Create a new key entry and paste the public key into the key field. The public key is the one from the .pub file, and it will start with something like:

ssh-ed25519 AAAA...

Do not paste your private key into Plesk. The private key stays on your machine and is what Codex will use to authenticate later.

Step 3: Generate a Dedicated SSH Key Pair in PowerShell

On your Windows machine, open PowerShell and generate a dedicated SSH key just for Codex:

ssh-keygen -t ed25519 -f $env:USERPROFILE\.ssh\codex_plesk -C "codex-plesk"

This creates two files:

codex_plesk
codex_plesk.pub

Use them like this:

• codex_plesk = private key → keep this on your PC
• codex_plesk.pub = public key → paste this into Plesk

Using a separate key pair for Codex makes the whole setup much easier to manage and revoke later if needed.

Step 4: Test the SSH Login Manually First

Before you even touch the Codex UI, prove that the SSH key works from your own terminal. Run a test command such as:

ssh -i ~/.ssh/codex_plesk system-user@your-server-ip

On the very first connection, you may get a host key prompt asking whether you want to trust the server. That is normal. After accepting it, you should see a successful login and something like the Ubuntu welcome banner.

This step matters because it confirms three separate things at once:

1. the server is reachable over SSH
2. the public key in Plesk matches your private key
3. the site's system user is allowed to log in

If this step fails, fix it here before trying to debug anything inside Codex.

Step 5: Add the SSH Connection in Codex

Open Codex and add a new SSH connection manually. Use the same details you just tested successfully:

• Host: your server IP or hostname
• User: the Plesk site system user
• Port: 22
• Private key: the path to codex_plesk

Use the private key file, not the .pub file. The public key only lives in Plesk so the server knows what to trust. Codex needs the private key on your own machine in order to authenticate.

If Codex detects the SSH connection but says Codex CLI is missing, that is expected at this stage.

Step 6: Install Codex CLI Without sudo

Once you are connected over SSH as the Plesk site user, install Codex CLI into that user's own home directory. We used a user-level npm prefix so there was no need for sudo:

mkdir -p ~/.npm-global
npm config set prefix ~/.npm-global
echo 'export PATH="$HOME/.npm-global/bin:$PATH"' >> ~/.bashrc
source ~/.bashrc
npm install -g @openai/codex@latest

Then confirm it installed correctly:

which codex
codex --version

This is a nice middle ground: Codex gets the tooling it needs, but the install stays inside the site user's own home directory and does not touch the global server environment.

Step 7: Sign In to Codex and Verify the Connection

Back in the Codex UI, the connection should now move on from the CLI warning. The final step is to sign in and authenticate Codex for that remote environment.

If prompted in the UI, click Sign in to Codex and complete the browser or device-code flow. If you ever need to do it manually over SSH, you can also run:

codex login

Once authentication is complete, you should see the connection become healthy and ready. A few useful checks are:

codex --version
codex status

At that point, Codex can work directly against your server through the Plesk site user.

Troubleshooting Common Connection Errors

If you are unable to establish a connection, check the following common issues:

• 'Permission Denied': Ensure your public key is added to the correct user account and not the global SSH folder.
• 'CLI Not Found': Verify your PATH includes ~/.npm-global/bin by running echo $PATH.
• Authentication Failures: Confirm your SSH client is specifically pointing to the private key generated in Step 3 using the -i flag.

Quick Reference Table

The table above summarises the handful of settings and commands that made the final working setup possible.

Common Pitfall: chrooted bash vs Normal bash

The biggest stumbling block for us was the shell mode in Plesk. On paper, /bin/bash (chrooted) feels like the obvious choice because it is more restrictive. In practice, it can hide tools that Codex needs, including node and npm, depending on how your server is set up.

That is why the final working route used normal /bin/bash instead. Yes, it is less restrictive than a chroot, so you should understand that trade-off. But paired with a dedicated site user, no sudo and a separate SSH key, it is still a practical and sensible setup for many real-world servers.

If you absolutely need a chroot, you can customise the Plesk chroot environment. Just be aware that it becomes a more advanced server administration task rather than a quick Codex setup.

Security Notes and Good Practice

A few final points are worth keeping in mind:

• Use a dedicated SSH key for Codex rather than reusing your general-purpose key
• Keep the private key private. Only the .pub file goes into Plesk
• Do not use root and do not give the site user unrestricted sudo
• Use the site's own system user where possible, rather than a broad server-wide account
• If the site shares a subscription with other domains, understand what that system user can already see and modify
• If you need to revoke access later, remove the public key from Plesk and delete the Codex connection

The aim here is not perfect zero-trust isolation. It is a practical working setup that keeps permissions scoped to the site user and avoids unnecessarily broad access.

Conclusion

If you have been wrestling with Codex, SSH and Plesk, the good news is that it does work cleanly once the pieces line up. The route that worked for us was not the most restrictive on paper, but it was the most practical in reality:

• enable SSH for the site's system user
• use normal /bin/bash
• authenticate with a dedicated SSH key pair
• test the login manually first
• connect through the Codex UI
• install Codex CLI into the user's own home directory

That gives you a reliable remote workflow without going anywhere near root access or a messy server-wide install.

If you're setting this up for the first time, take it one step at a time and verify each stage before moving on. It will save you a lot of head-scratching later.