The first session in a real repository must prove one thing: Codex sees the right project and acts inside the expected boundary. The temptation to install dependencies at once or run a mass refactor is strong but harmful - it mixes verifying the environment with the work and deprives you of a clean starting point. The right start is not a task but an inventory: first you look at the state yourself, then you give the agent a narrow exploration with no right to change.

Before launching it helps to look at git yourself and sign in in a predictable mode. git status --short --branch shows the starting point, and running codex with explicit flags --sandbox read-only and --ask-for-approval on-request sets a strict boundary for the first acquaintance. Read-only at the start is cheap insurance: the agent reads and proposes but touches nothing until you have raised the mode consciously. A clean start turns any subsequent diff into a meaningful picture rather than a riddle.

Right after signing in you check what actually loaded with the /status command. It shows the project root and current directory, the model, the active permission profile or sandbox mode, the approval policy, the writable roots and the context. This is a snapshot of the environment: until you have seen it, you do not know under what conditions the agent works. The project root especially matters - it is what confirms that Codex took the expected repository, not a neighboring directory that happened to be current.

The first request is worth making an exploration without changes rather than a broad task. It is sensible to ask to show the entry points, the install, lint, typecheck and test commands from the project files, the active AGENTS.md instructions and three risks before the first edit - with an explicit ban on installing dependencies and running network commands. Such a request gives a map of the project and a list of what cannot be reliably inferred from the code, without letting the agent prematurely edit a poorly understood repository.

Trust in the working directory here is a conscious decision, not a button on the way to work. Project-local configuration from .codex/ loads only after you have trusted the workspace, because it may contain executable settings written by someone else. In a version-controlled directory Codex usually proposes the Auto baseline: workspace-write and on-request. For an unknown or non-version-controlled folder it is safer to start with read-only and raise trust later.