Code Review

> /review

Review Findings:

[P1] Unvalidated user input in database query

The function `getUserById` in src/db.ts:42 uses user input directly in 
the SQL query without validation or parameterization, creating a SQL 
injection vulnerability. Attackers could execute arbitrary SQL commands.

Location: src/db.ts:42-45
Confidence: 0.95

```suggestion
const result = await db.query(
  'SELECT * FROM users WHERE id = $1',
  [userId]
);

try {
  const data = await fetchData(url);
  return data;
} catch (error) {
  logger.error('Failed to fetch data', { error });
  throw new AppError('Data fetch failed', { cause: error });
}

## Review Guidelines

The review agent follows these principles:

### What Gets Flagged

Issues are flagged when they:

1. **Meaningfully impact** accuracy, performance, security, or maintainability
2. **Are discrete and actionable** (not general codebase issues)
3. **Match the codebase's rigor level** (don't demand excessive rigor for scripts)
4. **Were introduced in the current changes** (not pre-existing bugs)
5. **The author would likely fix** if made aware
6. **Don't rely on unstated assumptions** about the codebase
7. **Are provably affected** (not just speculation)
8. **Aren't intentional changes** by the author

### What Doesn't Get Flagged

- Trivial style issues (unless they obscure meaning)
- Personal preferences
- Issues that violate unstated conventions
- Pre-existing bugs not touched by this change
- Speculative problems without concrete evidence
- Intentional design decisions

### Comment Guidelines

Review comments:

1. Are **clear about why** the issue is a bug
2. **Appropriately communicate severity** (no exaggeration)
3. Are **brief** (body is at most 1 paragraph)
4. Include **code chunks ≤3 lines** (use inline code or blocks)
5. **Explicitly state scenarios** where the bug arises
6. Use **matter-of-fact tone** (not accusatory or overly positive)
7. Are **immediately graspable** without close reading
8. **Avoid excessive flattery** and unhelpful comments

## Configuration

### Using a Different Review Model

You can configure a specific model for code review:

```toml
# ~/.codex/config.toml

# Use a more powerful model for reviews
review_model = "gpt-4o"

# Or use a specialized reasoning model
review_model = "o1-mini"

# Code Review Guidelines

## Security

- All database queries must use parameterized statements
- Never log sensitive data (passwords, API keys, PII)
- All user input must be validated before processing

## Performance

- Database queries in loops are not allowed
- Large datasets (>1000 items) must be paginated
- Heavy computations should be async or background jobs

## Testing

- All public API endpoints must have integration tests
- Business logic must have unit test coverage
- Mock external services in tests

# Make your changes
git add .

# Run review before committing
codex
> /review

# Address any findings
# Commit when review passes
git commit -m "Add user authentication"

# Checkout the PR branch
git checkout feature-branch

# Review the changes
codex
> /review

# Leave feedback or approve

# .github/workflows/review.yml
name: Code Review

on: [pull_request]

jobs:
  review:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      
      - name: Run Codex Review
        run: |
          codex exec "/review" --ephemeral
        env:
          OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }}

> /review
> "Review only the changes in src/auth/"

> /review
> "Focus on security vulnerabilities"

> /review
> "Check for performance issues only"

# First review
> /review

# Fix the issues
# ...

# Review again
> /review
> "Verify that the P1 security issue is fixed"