Getting Started with Codex on Ubuntu for Linux Work and Automation

Step 1: Choose a small Ubuntu project

Codex CLI is a coding agent that works from your terminal. Start with a folder you can inspect and a reversible task: build a report of files in a scratch directory. That teaches the same habits needed for Linux automation without beginning with service changes or system-wide cleanup.

Use your normal Ubuntu user. Install Git, Python and curl, then create a repository. Your source folder, model provider, credentials and execution permissions are separate choices. This guide uses ordinary Codex sign-in; a locally installed CLI does not by itself mean the model runs locally.

Open the complete copyable example — example-01.txt

# Open full code above.

Step 2: Install and authenticate Codex

Download and inspect the official Linux installer, then run it and confirm codex --version. Open a new shell if needed to pick up PATH changes. Launch codex in the lab directory and choose an available sign-in method. Account access and usage depend on the authentication option you use.

Start by asking ‘Explain this directory and propose a read-only file report.’ Read the plan before requesting edits. The official installation guide covers installation and initial sign-in; the CLI reference documents flags.

Open the complete copyable example — example-02.txt

# Open full code above.

Step 3: Write a useful AGENTS.md

Put project expectations in AGENTS.md so future sessions can see the same task boundaries. Include allowed paths, the output format and the verification command. A project instruction file guides behavior; operating-system permissions and sandbox settings provide separate enforcement.

Keep credentials out of this file. A concise file is easier to maintain than an enormous collection of unrelated instructions. Update it when the actual project workflow changes.

Open the complete copyable example — AGENTS.md.txt

# Open full code above.

Step 4: Build and inspect your first automation

Ask Codex: ‘Create report.py using only the Python standard library. List regular files directly inside scratch/ with name and size in bytes, sorted by name. Do not follow symbolic links. Write reports/files.json. Create the output directory if needed. Running twice should produce identical JSON. Do not modify the input files.’ This specification gives it a testable outcome.

Use a workspace-write sandbox for this bounded edit. Afterward inspect git diff, read report.py and run the verification below. The first diff does not show untracked files, so inspect git status and open newly created files too. Do not equate an agent’s success message with a checked result.

Open the complete copyable example — example-04.txt

# Open full code above.

Step 5: Make repeated runs predictable

Use codex exec for a bounded non-interactive request, such as explaining an existing script. For recurring file reports, schedule the deterministic report script itself once reviewed; you do not need to ask a model to rediscover the same logic each day. Keep model-driven planning and routine execution as distinct steps.

The read-only example below writes the final response to a report file through the CLI output option. It does not grant the agent permission to edit the repository. Before automating any write task, explicitly choose its sandbox and failure behavior. Non-interactive runs cannot rely on a human answering an interactive prompt.

Open the complete copyable example — example-05.txt

# Open full code above.

Step 6: Keep checkpoints and diagnose failures

Once you have read and checked the files, commit only the intended project files. Before the next task, use a branch and record the known-good result. For system administration, begin with inventory and a proposed change; service restarts, package removal and permission changes deserve their own clear scope.

Troubleshooting: command not found means inspect PATH and installation; authentication errors mean check the sign-in route; sandbox errors mean identify the exact required path or capability. Expand only the permission that the task needs. For a failed script, capture its exit code and reproduce it outside the model conversation.

Your first milestone is modest and useful: a repeatable script, a checked output and a readable change. In the next guide, OpenClaw adds persistent agent routing. For Japanese practice: ‘We check the result’ becomes the marked sentence in the opposite column.

Continue the series

• A DIY Violoop Alternative: GL-RM10 + Codex Automation, Step by Step
• Ollama on Ubuntu: Run a Small Model and Add Context Knowledge
• Getting Started with OpenClaw and Local Agents on Ubuntu
• LangGraph for Practical Workflows: State, Approval and Recovery