Local foundation

1. Establish the local directory layout

Keep repositories and helper scripts in predictable places

The local layer needs a stable structure. Repositories should not be scattered randomly across the machine, and helper scripts should have a clear home.

mkdir -p /Users/example/dev
mkdir -p /Users/example/bin
ls -la /Users/example

This gives the setup a clean split between project repos and local support scripts.

2. Install git and verify shell basics

Make sure the machine can actually do repo work

The laptop has to be able to clone repos, inspect branches, commit changes, and run shell commands cleanly.

git --version
which git
echo $SHELL
pwd

3. Keep the active repos in one workspace tree

Use a stable repo layout so scripts and agents can rely on it

The environment benefits from a consistent project root. That keeps paths predictable for both the user and the automation.

/Users/example/dev/project-a
/Users/example/dev/project-b
/Users/example/dev/project-c

It also makes it easier to reason about which repo a hook or helper script is operating on.

4. Install and verify the coding agents

Keep Claude and Codex available in the same environment

Once the shell and the repo layout exist, make sure both coding agents are actually available locally.

claude --help
codex --help

The value here is practical: the local machine can use either tool without changing environments or moving files around.

5. Add the local helper scripts directory to PATH

Make the local script layer easy to invoke

The helper scripts are much more useful if they can be called like normal shell commands.

# shell profile example
export PATH="/Users/example/bin:$PATH"
source ~/.zshrc

After that, a script in /Users/example/bin becomes part of the normal working environment.

6. Add the first helper scripts

Turn repeated local tasks into named commands

The local machine is where the helper scripts begin to matter. This is where scripts such as the Claude Stop hook, daily sync helpers, and setup audit scripts start to appear.

/Users/example/bin/claude_stop_hook.sh
/Users/example/bin/git_daily_sync.sh
/Users/example/bin/claude_setup_audit.sh
/Users/example/bin/codex_setup_audit.sh

7. Verify that local git activity is clean

Make sure the local repos are in a usable state

Before pushing local activity into a larger system, the repos need to behave cleanly at the shell level.

cd /Users/example/dev/project-a
git status
git branch
git log --oneline -5

This catches the boring mistakes early: wrong branch, untracked junk, or a repo that is not in the state the scripts expect.

8. Define the role of the local layer

Keep the laptop focused on execution, not persistence

By the end of this stage, the laptop has a clear role. It runs the agents, edits the code, invokes the scripts, and owns the fast local feedback loop. It does not need to become the durable memory layer.

That separation is important because it keeps the local machine fast and flexible while leaving long-term continuity to the VPS side.