config: accept both ghp_ and github_pat_ tokens in schema

[benvinegar]

The .env.schema had startsWith=ghp_ on GITHUB_TOKEN, which rejects fine-grained PATs (github_pat_ prefix). This caused varlock validation to fail and the agent to crash-loop on startup.

Varlock doesn't support multiple startsWith values, so the prefix constraint is removed from the schema. The soft validation in config.sh still warns on unexpected prefixes.

[greptile-apps]

Greptile Summary

This PR fixes a crash-loop on startup caused by varlock rejecting fine-grained GitHub PATs (github_pat_ prefix) because the schema only allowed the classic ghp_ prefix. The fix removes the startsWith=ghp_ constraint from .env.schema, leaving soft prefix validation in config.sh as the only prefix check.

Key observations:

• The core fix is correct: varlock's schema validation was too strict, blocking a legitimate and increasingly preferred token type.
• The config.sh soft-validation already accepts both ghp_|github_pat_ — no change needed there.
• redact-logs.sh already redacts both token formats — no gap there.
• bin/security-audit.sh still scans only for ghp_[a-zA-Z0-9]{36} in its secret-exposure and git-history checks (lines 281, 332, 336); fine-grained PATs will not be detected if they leak. This is a pre-existing gap exposed by officially supporting the second token format.
• CONFIGURATION.md still shows ghp_... as the only example placeholder; minor doc inconsistency with the updated schema comment.

Confidence Score: 4/5

• Safe to merge; the fix is minimal and correct, with no functional regressions.
• The one-line schema change is straightforward and directly addresses the reported crash. Soft validation in config.sh already handles both prefixes. The only gaps are a pre-existing blind spot in security-audit.sh (fine-grained PATs not scanned) and a doc example still showing only ghp_, neither of which is a blocker.
• bin/security-audit.sh — should add github_pat_ to secret-scanning patterns to match redact-logs.sh

Important Files Changed

Filename	Overview
.env.schema	Removes startsWith=ghp_ constraint on GITHUB_TOKEN to accept both classic (ghp_) and fine-grained (github_pat_) PATs. The soft validation in config.sh already covers both prefixes. Minor: CONFIGURATION.md still shows ghp_... as the only example token format.

Sequence Diagram

sequenceDiagram
    participant Admin
    participant install.sh
    participant config.sh
    participant varlock
    participant agent as baudbot_agent

    Admin->>install.sh: run install / config
    install.sh->>config.sh: prompt for GITHUB_TOKEN
    config.sh-->>Admin: warn if prefix ≠ ghp_ or github_pat_
    Admin->>config.sh: supply token (ghp_... or github_pat_...)
    config.sh->>config.sh: write to ~/.config/.env
    agent->>varlock: varlock load (.env.schema)
    Note over varlock: @type=string (no prefix constraint)
    varlock-->>agent: validation passes for both token types
    agent->>agent: start successfully

Loading

_{Last reviewed commit: 35ab91a}

[greptile-apps]

_{1 file reviewed, 2 comments}

_{Edit Code Review Agent Settings | Greptile}

[greptile-apps]

Unrestricted string type accepts any value

Removing startsWith=ghp_ is correct, but dropping to a plain @type=string with no constraint means varlock will accept any non-empty string as a valid GITHUB_TOKEN (e.g. a mistyped value, a pasted Slack token, etc.). The sole guard is now the prefix-warning in config.sh, which only fires during interactive setup — not on every restart.

Varlock doesn't support multiple startsWith values in a single annotation, but it does support a pattern (regex) constraint. If varlock's schema supports a @type=string(pattern=...), you could capture both prefixes without losing all validation:

Suggested change

	# @required @type=string
	# @required @type=string(pattern=^(ghp_|github_pat_))

If varlock doesn't support pattern, a comment documenting the intentional lack of prefix validation here would help future maintainers understand why the constraint was removed rather than replaced.

Prompt To Fix With AI

This is a comment left during a code review.
Path: .env.schema
Line: 37:37

Comment:
**Unrestricted string type accepts any value**

Removing `startsWith=ghp_` is correct, but dropping to a plain `@type=string` with no constraint means varlock will accept any non-empty string as a valid `GITHUB_TOKEN` (e.g. a mistyped value, a pasted Slack token, etc.). The sole guard is now the prefix-warning in `config.sh`, which only fires during interactive setup — not on every restart.

Varlock doesn't support multiple `startsWith` values in a single annotation, but it does support a `pattern` (regex) constraint. If varlock's schema supports a `@type=string(pattern=...)`, you could capture both prefixes without losing all validation:

```suggestion
# @required @type=string(pattern=^(ghp_|github_pat_))
```

If varlock doesn't support `pattern`, a comment documenting the intentional lack of prefix validation here would help future maintainers understand why the constraint was removed rather than replaced.

How can I resolve this? If you propose a fix, please make it concise.

[greptile-apps]

Related files not updated for fine-grained PAT support

Two companion files still only handle the ghp_ prefix and may need updating:

1. bin/security-audit.sh (lines 281, 332, 336) — the secret-scanning regex patterns use only ghp_[a-zA-Z0-9]{36}. Fine-grained PATs with the github_pat_ prefix won't be detected by the audit's secret-exposure or git-history scans. redact-logs.sh already handles both prefixes correctly, but security-audit.sh has not been updated to match.

2. CONFIGURATION.md (line 113) — the example env block still shows only a classic token placeholder. Updating it to reference both token formats would keep the docs consistent with the schema comment and the description in AGENTS.md.

Prompt To Fix With AI

This is a comment left during a code review.
Path: .env.schema
Line: 36:39

Comment:
**Related files not updated for fine-grained PAT support**

Two companion files still only handle the `ghp_` prefix and may need updating:

1. **`bin/security-audit.sh`** (lines 281, 332, 336) — the secret-scanning regex patterns use only `ghp_[a-zA-Z0-9]{36}`. Fine-grained PATs with the `github_pat_` prefix won't be detected by the audit's secret-exposure or git-history scans. `redact-logs.sh` already handles both prefixes correctly, but `security-audit.sh` has not been updated to match.

2. **`CONFIGURATION.md`** (line 113) — the example env block still shows only a classic token placeholder. Updating it to reference both token formats would keep the docs consistent with the schema comment and the description in `AGENTS.md`.

How can I resolve this? If you propose a fix, please make it concise.