Connect Claude Code or Codex to cPanel: complete Windows and Mac setup Print

  • claude code, ssh, cpanel, local development
  • 0

Quick answer

Use a coding agent on your own computer with a separately tested SSH/SFTP connection, a current backup, and a reviewed deployment. This complete workflow covers Windows and macOS, public-key authorization, server identity, the exact website folder, editing, verification, recovery, and revocation. Your private key stays on your computer.

Choose your website-building guide

1. Confirm the account and choose the local workflow

This guide runs Codex or Claude Code on your own computer, with SSH or SFTP used only for approved remote operations. You do not need to install the coding tool on the hosting account for this workflow. A remote-agent environment has additional requirements and is covered separately.

Open your Interactive Online Client Area, select the intended service, and record the cPanel username, hosting server, SSH port, domain, and account status. Ask support for anything missing. Do not substitute your billing email for the server username or guess the SSH port. Confirm that this exact account has shell/SFTP access; Free does not, and package features are not proof that every account restriction has been removed.

Identify the CMS or framework. For a WordPress text change, the editor or a narrow REST API integration may be the better tool. For a code change, use a local copy or staging site and make the deployment target explicit.

2. Install the official coding tool and test OpenSSH

Install Claude Code or Codex from the applicable official installation page below, using the instructions for your operating system. Review the installer source before running it, open a fresh terminal, and complete the supported sign-in flow. The AI subscription or API login is separate from your hosting login.

On Windows, use PowerShell or Windows Terminal and check that the OpenSSH Client optional feature is available. On macOS, use Terminal. Run ssh -V to confirm that an SSH client is present. Keep one consistent environment: Windows OpenSSH, Git Bash, and WSL can use different home folders and key files.

Create a dedicated local project folder, download or clone the relevant source, and keep a clean baseline. Exclude private keys, .env files, full database dumps, backups, and customer exports from the repository and from material supplied to the AI tool.

3. Generate a named key on your computer

First check whether the proposed private-key filename already exists. Do not overwrite an existing identity accidentally. The examples use RSA 4096 for broad cPanel import compatibility. A different modern key type can be appropriate when your account supports it.

Enter a strong passphrase only when your local terminal prompts for it. Store the passphrase securely. The command creates a private file named website_ai and a public file named website_ai.pub; the private file must remain outside the website and repository.

If the SSH key folder is missing, create it first with the command for your operating system. Creating the folder does not authorize a key or replace an existing key file. Recheck the proposed filename before generating the key.

# Windows PowerShell
New-Item -ItemType Directory -Force -Path "$env:USERPROFILE/.ssh" | Out-Null
ssh-keygen -t rsa -b 4096 -f "$env:USERPROFILE/.ssh/website_ai"

# macOS Terminal
mkdir -p ~/.ssh
chmod 700 ~/.ssh
ssh-keygen -t rsa -b 4096 -f ~/.ssh/website_ai

4. Import only the public key and authorize it

  1. On Windows, read the public file with Get-Content "$env:USERPROFILE/.ssh/website_ai.pub". On macOS, use cat ~/.ssh/website_ai.pub. Copy the complete public line, not the private file.
  2. In the correct cPanel account, open SSH Access, Manage SSH Keys, then Import Key. Give it a recognizable device/workflow name, paste the public key into the public-key field, and leave the private-key field empty.
  3. After import, find the key in the Public Keys list, choose Manage, and select Authorize. Compare the public fingerprint with your local key record. If SSH Access is missing, stop and ask support about the account capability.

5. Create and verify an SSH alias

Edit your local SSH config: %USERPROFILE%/.ssh/config on Windows or ~/.ssh/config on macOS. Add the following example with your real connection details. Use forward slashes in a Windows IdentityFile path, such as C:/Users/YOUR_WINDOWS_USER/.ssh/website_ai, if the home shortcut is ambiguous.

Host website-staging
  HostName YOUR_HOSTING_SERVER
  User YOUR_CPANEL_USERNAME
  Port YOUR_SSH_PORT
  IdentityFile ~/.ssh/website_ai
  IdentitiesOnly yes

Check the SSH config before connecting

After replacing every placeholder, run ssh -G website-staging. This prints the resolved configuration without logging in. Check hostname, user, port and identityfile. A literal placeholder or the wrong key path needs correction before the connection attempt. This check does not prove server access or verify the server fingerprint.

Run ssh website-staging. On the first connection, compare the server host fingerprint against a value obtained independently from trusted support or an already verified management channel. Accept it only when it matches. Do not disable StrictHostKeyChecking or erase a mismatch warning merely to continue.

After login, verify the account and working directory with a harmless read. Open cPanel Domains to confirm the exact document root for the intended site, then compare it with the remote files. Exit the session after the check.

6. Give Claude Code or Codex a limited task

Open the local project directory and start Claude Code with claude or Codex with codex. Tell the tool the project folder, tested SSH alias, exact remote document root, affected URL, desired result, and exclusions. It can use the local connection without seeing the private key or passphrase in chat.

A useful first request is: "Inspect this local project and the approved staging folder read-only. Confirm the CMS, target domain, and files involved. Propose the smallest change and verification plan. Do not publish, send email, alter billing, install software, or change other sites."

Keep command and write permissions appropriate to this task. A network restriction or approval prompt should be resolved deliberately, not by turning off every protection. Review the returned account/path evidence before authorizing any write.

7. Back up, edit, preview and deploy

  1. Capture the current remote files immediately before deployment, using SFTP download or the supported backup tool. Include the relevant database when the task changes data or CMS configuration. Store recovery material outside the public site and verify it is readable.
  2. Implement locally or on an isolated stage. Review the diff for unrelated changes, placeholder business claims, new dependencies, and leaked secrets. Run the relevant syntax/build checks and inspect desktop and phone behavior.
  3. Reconcile any newer live changes before release. Approve a named artifact and exact destination, then upload only the intended files through the tested secure connection. A successful upload to a different folder is not a deployment to this website.
  4. Read back the changed files or hashes and open the actual HTTPS URL. Check the affected interaction, navigation, assets, and relevant forms or commerce behavior. Record the source version, destination, time, and result.

8. Roll back or troubleshoot safely

If the release fails, restore the specifically changed files from the verified pre-deployment copy and test again. Restore a database only under a deliberate plan that preserves newer orders, customers, and content. Do not replace the whole account because one file failed.

Permission denied (publickey): compare username, authorized public fingerprint, and IdentityFile. Timeout or refusal: check the documented host/port, VPN/firewall, and provider restrictions. Missing shell: use a supported plan or another approved editing method. Wrong page: recheck document root, domain mapping, cache, and filename case.

If the AI tool cannot execute a command that works in your own terminal, inspect that session's environment, working directory, network permission, and approval settings. Send support the domain, approximate time/time zone, connection method, and sanitized error. Never send a private key, passphrase, API token, or session URL.

When the workflow is retired, deauthorize its public key and revoke any separate CMS/API credentials. Keep the final source and recovery record so a new session can continue without guessing.

Related help

Official references

Reviewed October 31, 2026. Interfaces, vendor availability, and account features can change. Check your current account before making changes.


Was this answer helpful?

« Back