Turning a Proxmox LXC into a Codex Remote Devbox

Coding agents become more useful, and more awkward, when they stop being short terminal sessions.

A Codex session can inspect a repository, edit files, run tests, hit a missing dependency, ask for approval, or pause because it needs a small decision from me. That is fine when I am at the keyboard. It is less useful when the session is tied to my laptop and I am away from it.

That was the reason for this experiment. Instead of keeping my notebook awake just because Codex might need attention later, I ran codex remote-control inside a Linux LXC container on my Proxmox host.

The question was not whether I could “code from my phone”. I do not think that is the interesting part. The better question was: can a small, isolated, always-on Linux container act as a persistent Codex devbox that I can supervise remotely?

In my setup, yes. With caveats.

What `codex remote-control` is

The official Codex CLI reference lists codex remote-control as an experimental command. Its job is to ensure that the local app-server daemon is running with remote-control support enabled.

That wording matters. This is not the same as exposing codex app-server --listen on a public interface and hoping for the best. OpenAI documents app-server separately, and the remote connections documentation explicitly warns against exposing app-server transports directly on shared or public networks.

The official remote connections page describes a broader model: Codex can be used from another device to continue threads, send follow-up instructions, approve commands, review outputs, inspect diffs, see test results, and switch between connected hosts and threads.

In that model, the connected host still matters. The remote device is the control surface. The host provides the repository files, shell, tools, credentials, permissions, plugins, MCP servers, browser setup, and sandbox settings.

That maps well to a devbox.

Why I used a Proxmox LXC

I already run Proxmox in my homelab, so an LXC container was the easiest place to test this.

An LXC gives me a small Linux environment that can stay online without keeping my main workstation awake. It is lighter than a full VM, easy to snapshot, and simple to throw away if I do not like the result.

I would not describe LXC as a hard security boundary for hostile workloads. For this use case, I treat it as a practical isolation layer for a personal dev environment.

The useful properties are straightforward:

The container can stay online while my laptop is off.
I can run Codex as a normal user instead of root.
I can clone only the repositories I want Codex to work on.
I can install a narrow set of project dependencies.
I can snapshot the container before large changes.
I can limit CPU, memory, and disk from Proxmox.
I can rebuild the environment without touching my main machine.

That is the main reason this setup makes sense to me. Codex gets a persistent Linux workspace, but not my whole personal workstation.

The setup model

My setup looks like this conceptually:

Phone or desktop Codex UI
        |
        | remote control
        |
Proxmox host
        |
        +-- LXC container
              +-- non-root Linux user
              +-- cloned repositories
              +-- language runtimes and test tools
              +-- authenticated Codex CLI
              +-- codex remote-control

Inside the container, I keep the environment boring:

# as a normal user, not root
codex remote-control

Some community examples also show:

codex features enable remote_control

I would verify that on the actual Codex CLI version before publishing it as a required step. I found that command in a Reddit report about running remote-control on Linux CLI with systemd, not in the official CLI reference section I checked.

After the manual command works, a user-level systemd service can keep it running:

# ~/.config/systemd/user/codex-remote-control.service
# Example only. Check `command -v codex` and adjust PATH first.
# Run as a normal user, not root.

[Unit]
Description=Codex remote-control daemon
Wants=network-online.target
After=network-online.target

[Service]
Type=simple
WorkingDirectory=%h
Environment=PATH=%h/.local/bin:%h/.local/share/npm/bin:/usr/local/bin:/usr/bin:/bin
ExecStart=/usr/bin/env codex remote-control
Restart=on-failure
RestartSec=10

[Install]
WantedBy=default.target

Then:

systemctl --user daemon-reload
systemctl --user enable --now codex-remote-control.service
systemctl --user status codex-remote-control.service
journalctl --user -u codex-remote-control.service -f

I would not start with the service. First run codex remote-control manually, confirm the host appears, confirm commands execute inside the container, and only then make it persistent.

What worked

The container acted like a remote Codex machine.

The important part is that the repository, shell commands, installed dependencies, and local Codex state lived inside the LXC. I could leave the container online, start or continue work there, and supervise the session from another device.

That fits the official model: the remote device sends prompts and approvals, while the connected host provides the actual development environment. OpenAI’s announcement about working with Codex from anywhere frames the same direction at the product level: keep work reachable across devices, especially when a task needs review or input.

For me, that is more useful than coding on mobile. The valuable workflow is checking whether a session is blocked, approving a command, reading test output, inspecting a diff, or redirecting the task while I am away from the desk.

Where this is useful

I can see this being useful for:

Long refactors in personal projects.
Test runs that may need approval or follow-up.
Dependency upgrades.
Bug investigations.
Homelab automation experiments.
VPS-based development environments.
Per-project Linux containers with different stacks.
Keeping an agent available without keeping a laptop awake.

This is not a replacement for a real review. It is a way to keep work moving when the agent needs a small amount of supervision.

That pattern already existed informally before this workflow was documented. In an openai/codex discussion about remote or headless control, users described wanting to run Codex on one machine and control it from another device. Some people reached for SSH, Tailscale, and tmux as the practical workaround. That is a useful sign: the need was already there before the command had a cleaner shape.

Security model

I treat the container as sensitive.

Codex can read files, edit code, run commands, and use whatever credentials are available to the user running it. Remote control does not reduce that risk. It just gives me another way to reach the machine.

My baseline rules for this setup are:

Do not run Codex as root.
Do not expose app-server directly to the internet.
Use the official Codex remote flow, SSH, VPN, WireGuard, or Tailscale.
Keep secrets out of the container unless they are required.
Avoid mounting the Proxmox host filesystem.
Avoid mounting the Docker socket unless you accept the host-level risk.
Use firewall rules.
Snapshot before large experiments.
Use separate containers for separate trust levels.
Be cautious with third-party remote UI tools.

That last point is worth spelling out. There have already been reports of malicious third-party packages targeting Codex users and authentication tokens. TechRadar covered a case where a package presented as a Codex-related UI tool was linked to token theft, which is enough for me to keep this path boring: official Codex remote control, SSH, and private networking.

Operational problems to expect

This is still experimental.

The CLI marks codex remote-control as experimental, so I would not build a critical workflow around it without fallback access through SSH. I also would not assume the daemon will behave like a mature production service.

There are already community and GitHub reports of rough edges. One GitHub issue describes a Linux/Raspberry Pi host disappearing from the mobile app until app-server was restarted. Another issue describes remote-control startup failing because local SQLite state under ~/.codex became corrupt.

That changes how I operate it. I keep SSH access available and expect to use basic diagnostics:

codex doctor
systemctl --user status codex-remote-control.service
journalctl --user -u codex-remote-control.service -n 200

I would also be careful with network-mounted home directories. If Codex stores local state under ~/.codex, unreliable storage can turn into a remote-control problem that looks like a network issue.

Is Proxmox LXC an officially documented Codex target?

Not specifically, from what I found.

The official documentation validates the general model: remote machines, SSH hosts, always-on computers, remote development environments, approvals, diffs, test output, and secure relay behavior.

The Proxmox LXC part is my inference and implementation. A container on Proxmox is a practical way to create an always-on Linux devbox. It is not a special OpenAI-supported Proxmox integration.

That distinction is important. I would describe this as a valid use case, not an official recipe.

How I would start

I would start with a disposable container and a low-risk repository.

Create a fresh LXC. Add a normal user. Install Codex CLI and the project dependencies. Authenticate Codex. Run codex remote-control manually. Confirm the machine appears from the remote interface. Confirm that commands run inside the container. Then ask Codex to do something small, like inspect a test failure or update documentation.

Only after that would I add systemd. Only after that would I consider using it with more important repositories.

I would not begin by adding production secrets, broad SSH keys, host mounts, or Docker socket access.

The setup is useful because it is simple: Proxmox gives me a persistent, isolated Linux environment; Codex remote-control gives me a way to supervise long-running work from another device. That is enough for a personal homelab devbox.

What codex remote-control is