Option 1
Do not start Codex from the parent folder unless you need all projects.
For each Laravel project, add ignore files:
cat > .codexignore <<'EOF'
vendor/
node_modules/
storage/
bootstrap/cache/
public/build/
public/hot
.git/
.env
*.log
*.zip
*.sql
*.dump
*.bak
EOFOption 2
Also add/update AGENTS.md inside each project:
# Professnow Laravel project
Only inspect files relevant to the requested task.
Do not scan:
- vendor/
- node_modules/
- storage/logs/
- bootstrap/cache/
- public/build/
- .env
Before editing, identify the exact files needed.
Prefer small, targeted changes.
Do not refactor unrelated code.Option 3
Use targeted prompts like:
Fix the booking status issue. Look only in routes/web.php, app/Http/Controllers, app/Models, and resources/views/bookings.Avoid prompts like:
Analyze this whole projectExample, If you have multiple microservices
root@ip-172-31-1-90:/opt/lampp/htdocs/professnow# ls -1
admin-new
bookings-new
category-new
customer-managers-new
gallery
notification-new
professional-new
professnow-newUse this structure:
/opt/lampp/htdocs/professnow/
├── AGENTS.md # global rules
├── .codexignore # global ignore
├── admin-new/
├── bookings-new/
...
Create global .codexignore:
cd /opt/lampp/htdocs/professnow
cat > .codexignore <<'EOF'
**/vendor/
**/node_modules/
**/storage/
**/bootstrap/cache/
**/public/build/
**/public/hot
**/.git/
**/.env
**/error_log
**/nohup.out
**/*.log
**/*.zip
**/*.sql
**/*.dump
**/*.bak
EOF
Create global AGENTS.md:
cat > AGENTS.md <<'EOF'
# Professnow workspace rules
This workspace contains multiple separate projects.
Projects:
- admin-new: admin panel
- bookings-new: bookings service/app
- category-new: category service/app
- customer-managers-new: customer manager app
- gallery: standalone PHP/gallery assets
- notification-new: notification service/app
- professional-new: professional app
- professnow-new: main Professnow app
Rules:
- Do not scan all projects unless explicitly asked.
- First identify which project is relevant.
- Work inside only one project at a time.
- Ignore vendor, node_modules, storage, logs, cache, build files, backups, and env files.
- Before editing, list the exact files you plan to inspect.
- Make small targeted changes only.
- Do not refactor unrelated code.
EOF
Then add per-project ignore files:
for d in admin-new bookings-new category-new customer-managers-new notification-new professional-new professnow-new; do
cat > "$d/.codexignore" <<'EOF'
vendor/
node_modules/
storage/
bootstrap/cache/
public/build/
public/hot
.git/
.env
error_log
nohup.out
*.log
*.zip
*.sql
*.dump
*.bak
EOF
done
For gallery:
cat > gallery/.codexignore <<'EOF'
images/
galleries/
gallery/
single/
*.zip
*.bak
*.log
EOF
Best daily usage:
cd /opt/lampp/htdocs/professnow/bookings-new
codex
Not:
cd /opt/lampp/htdocs/professnow
codex
Prompt style:
Work only in bookings-new. Inspect routes, controllers, models, and related views only. Do not scan other projects.
This will save the most credit.
Option 4
Short Tutorial: Codex Memories
~/.codex/memories/ is where Codex stores local memories so it can remember useful context from previous sessions. Memories are off by default, so you need to enable them first. (OpenAI Developers)
1. Enable memories
Open Codex config:
mkdir -p ~/.codex
nano ~/.codex/config.toml
Add:
[features]
memories = true
Your user-level Codex config lives at:
~/.codex/config.toml
2. Check memory folder
ls -la ~/.codex/memories
If it is empty or missing at first, that is normal. Codex may create memory later after sessions become eligible.
3. Use /memories inside Codex
Inside Codex, type:
/memories
Use this to control whether the current thread can:
use existing memories
generate future memories
Thread choices do not change your global config. (OpenAI Developers)
4. What to save
Good memory:
Remember that I prefer small, targeted changes.
Remember that I usually want tests run before final answers.
Remember that this project uses Laravel and MySQL.
Remember not to scan vendor, node_modules, storage, or build folders unless needed.
Bad memory:
Remember my database password.
Remember my API key.
Remember production customer data.
Remember my SSH private key.
5. Recommended config
[features]
memories = true[memories]
use_memories = true generate_memories = true disable_on_external_context = true min_rollout_idle_hours = 6 max_rollout_age_days = 30 max_unused_days = 30
These memory settings are documented in Codex’s configuration reference. (OpenAI Developers)
6. Memory vs AGENTS.md
Use memory for things Codex can recall:
I prefer short explanations.
I usually work in Laravel.
I like small commits.
Use AGENTS.md for rules Codex must follow:
Do not edit generated files.
Do not expose secrets.
Run tests before finishing.
Do not refactor unrelated code.
Codex supports AGENTS.md as reusable project guidance. (OpenAI Developers)
7. Delete memories
rm -rf ~/.codex/memories
This removes saved memories, but if memory is still enabled, Codex may create new ones later.
8. Disable memories
[features]
memories = false[memories]
use_memories = false generate_memories = false
Simple rule
Use:
Memory = helpful recall
AGENTS.md = strict rules
Prompt = current task
That is the best practical setup.
Option 4 – Codex Memories
~/.codex/memories/ is where Codex stores local memories so it can remember useful context from previous sessions.
Memories are useful for saving recurring preferences, project context, coding style, and workflow habits.
1. Enable Memories
Open your Codex config file:
mkdir -p ~/.codex
nano ~/.codex/config.toml
Add this:
[features]
memories = true
2. Check the Memory Folder
Run:
ls -la ~/.codex/memories
If the folder is missing or empty at first, that can be normal. Codex may create memory files later after enough useful sessions.
3. Use /memories Inside Codex
Inside Codex, type:
/memories
Use this to control whether the current Codex session can:
Use existing memories
Generate future memories
This is useful when working on sensitive or temporary tasks.
4. What to Save in Memory
Good examples:
Remember that I prefer small, targeted changes.
Remember that I like short explanations after code changes.
Remember that this project uses Laravel and MySQL.
Remember not to scan vendor, node_modules, storage, logs, or build folders unless needed.
5. What Not to Save
Avoid saving secrets or private production data:
Database passwords
API keys
SSH private keys
.env values
Customer data
Production tokens
Memory is for reusable working context, not secrets.
6. Recommended Config
[features]
memories = true[memories]
use_memories = true generate_memories = true disable_on_external_context = true min_rollout_idle_hours = 6 max_rollout_age_days = 30 max_unused_days = 30
This enables memory while keeping it reasonably controlled.
7. Memory vs AGENTS.md
Use memory for helpful recall:
I prefer small commits.
I usually work with Laravel.
I like concise summaries.
Use AGENTS.md for strict rules:
Do not expose secrets.
Do not edit generated files.
Run tests before finishing.
Do not refactor unrelated code.
Simple rule:
Memory = helpful recall
AGENTS.md = strict rules
Prompt = current task
8. Delete Memories
To remove all saved memories:
rm -rf ~/.codex/memories
If memories are still enabled, Codex may create new ones later.
9. Disable Memories
Edit:
nano ~/.codex/config.toml
Set:
[features]
memories = false[memories]
use_memories = false generate_memories = false
10. Best Practice
Use Codex memories to reduce repeated explanations, but do not rely on memory alone.
Best setup:
~/.codex/memories/ = learned context
~/.codex/AGENTS.md = personal rules
project/AGENTS.md = project rules
current prompt = current task
Option 7 – graphify Graphify turns your project into a knowledge graph so Codex can understand the code structure
Short Tutorial: Graphify with Codex
Graphify turns your project into a knowledge graph so Codex can understand the code structure before searching files randomly. It creates files like graphify-out/GRAPH_REPORT.md, graphify-out/graph.json, and graphify-out/graph.html. The latest GitHub release shown is v0.5.0, released April 23, 2026. (GitHub)
1. Install Graphify
The official package name is graphifyy, but the command is graphify.
pipx install graphifyy
Or:
pip install graphifyy
Check:
graphify --help
2. Enable Codex Multi-Agent
Edit Codex config:
mkdir -p ~/.codex
nano ~/.codex/config.toml
Add:
[features]
multi_agent = true
Codex needs multi_agent = true for Graphify parallel extraction. (GitHub)
3. Install Graphify for Codex
Go to your project:
cd /path/to/your/project
Install Codex integration:
graphify codex install
Or:
graphify install --platform codex
This writes Graphify guidance into AGENTS.md and installs a Codex hook in .codex/hooks.json, so Codex is reminded to use the graph before broad file searching. (GitHub)
4. Create the Graph
From terminal:
graphify .
Inside Codex, use:
$graphify .
Important: for Codex, use $graphify, not /graphify. (PyPI)
5. Use Graphify in Codex
After graph is created, ask Codex like this:
Use Graphify first. Read graphify-out/GRAPH_REPORT.md before searching files. Identify the relevant modules, then inspect only the needed files.
Example:
Use Graphify first and find where login is handled. Do not grep the whole project until you read GRAPH_REPORT.md.
6. Useful Graphify Commands
Build graph:
graphify .
Update graph after code changes:
graphify . --update
Ask graph a question:
graphify query "how does authentication work?"
Explain one node/file/class:
graphify explain "UserController"
Find path between two concepts:
graphify path "User" "Payment"
7. Best Workflow with Codex
cd /path/to/project
graphify codex install
graphify .
codex
Inside Codex:
$graphify .
Then prompt:
Use Graphify before search. Read GRAPH_REPORT.md first, then make a small targeted change.
Simple Rule
Graphify = project map
GRAPH_REPORT.md = summary Codex should read first
$graphify . = run Graphify inside Codex
graphify . --update = refresh graph after changes
Option 6 – .graphifyignore tells Graphify which files and folders to skip when building a project knowledge graph.
Short Tutorial: .graphifyignore
.graphifyignore tells Graphify which files and folders to skip when building a project knowledge graph.
It works like .gitignore.
Use it to avoid scanning:
vendor/
node_modules/
logs/
cache/
.env files
large media files
database dumps
build output
This makes Graphify faster, cleaner, and safer.
Why Use .graphifyignore?
Without .graphifyignore, Graphify may scan unnecessary files like:
vendor/
node_modules/
storage/logs/
public/build/
.env
*.sql
*.zip
That can make the graph noisy and may waste time or tokens.
With .graphifyignore, Graphify focuses only on useful project files.
Create .graphifyignore
Go to your project folder:
cd /path/to/your/project
Create the file:
nano .graphifyignore
Or use:
cat > .graphifyignore <<'EOF'
vendor/
node_modules/
storage/
bootstrap/cache/
public/build/
.env
*.log
*.sql
*.zip
EOF
Basic Example
vendor/
node_modules/
.env
*.log
*.zip
This tells Graphify to ignore:
vendor/ dependency files
node_modules/ npm packages
.env secrets/config file
*.log log files
*.zip archive files
Laravel Example
vendor/
node_modules/
storage/
bootstrap/cache/
public/build/
public/hot
.env
.env.*
*.log
*.sql
*.dump
*.zip
*.bak
Good for Laravel projects because it skips dependencies, cache, logs, environment files, and database dumps.
Node / React Example
node_modules/
dist/
build/
coverage/
.next/
.nuxt/
.env
.env.*
*.log
Good for frontend projects because it skips dependencies, build output, test coverage, and environment files.
Python Example
.venv/
venv/
__pycache__/
.pytest_cache/
.mypy_cache/
dist/
build/
.env
*.log
*.db
*.sqlite
Good for Python projects because it skips virtual environments, caches, build files, logs, and local databases.
Large Workspace Example
For a folder with multiple apps:
**/vendor/
**/node_modules/
**/storage/
**/bootstrap/cache/
**/public/build/
**/.env
**/*.log
**/*.sql
**/*.zip
The **/ pattern means “match this folder or file anywhere inside the workspace.”
Example:
**/vendor/
matches:
app1/vendor/
app2/vendor/
backend/vendor/
Run Graphify After Creating It
graphify .
Graphify will now skip everything listed in .graphifyignore.
Best Practice
Keep .graphifyignore strict.
A good rule:
Ignore anything that is generated, secret, huge, cached, or not written by your team.
Useful files to keep:
app/
src/
routes/
config/
database/migrations/
resources/views/
README.md
AGENTS.md
composer.json
package.json
Files to ignore:
vendor/
node_modules/
storage/
logs/
.env
build/
dist/
*.sql
*.zip
Final Example
# Dependencies
vendor/
node_modules/
# Secrets
.env
.env.*
# Logs and cache
storage/
bootstrap/cache/
*.log
# Build output
public/build/
dist/
build/
# Backups and dumps
*.sql
*.dump
*.zip
*.bak
This is enough for most projects.