feat: Built-in agent — LLM-powered AEO analyst with chat API

[arberx]

Summary

• Built-in LLM-powered agent with chat API, thread persistence in SQLite, and 9 domain-specific AEO tools (visibility runs, timeline analysis, evidence lookup, competitor analysis, keyword management, sitemap inspection, etc.)
• CLI command (canonry agent) for interactive terminal chat sessions
• Multi-provider support — agent threads can use OpenAI, Claude, or Gemini as the backing LLM
• Security hardening — project ownership verification on thread endpoints, SSRF protection with DNS resolution on sitemap inspection, project-scoped run access
• Bug fixes — history windowing (newest messages kept, not oldest), complete evidence across all runs, malformed JSON recovery for Claude message replay

Commits

1. feat: built-in agent — LLM-powered AEO analyst with chat API — core agent loop, tools, store, routes, CLI command, DB migrations
2. fix(security): Add project ownership verification to thread endpoints
3. fix(agent): Add error handling for malformed JSON in tool call arguments
4. perf(agent): Move dynamic imports to top-level
5. refactor(agent): Replace circular HTTP self-calls with direct service layer
6. style(agent): Remove dead code and unused types
7. fix(agent): fix 5 bugs in agent loop, SSRF validation, and services — history windowing, SSRF validation, project-scoped getRun, complete getHistory, Claude replay fix

Test plan

• CI passes (typecheck, lint, test)
• SSRF validation tests cover IPv6 loopback, link-local, ULA, localhost, DNS resolution
• Manual: canonry agent interactive session against a project with runs
• Manual: verify thread persistence across server restarts

🤖 Generated with Claude Code

[arberx]

🤖 Automated Review Summary

Files reviewed: 21
Comments left: 13

Issues found:

• 🔴 Bug: 5
• 🟡 Security: 2
• 🟠 Performance: 1
• 🔵 Type Safety: 2
• 🟣 Testing: 1
• ⚪ Style: 1
• ⚪ Dead code: 1

Key findings

Bugs (fix before merge):

1. Tool-call persistence ordering (loop.ts ~line 188) — assistant tool-call rows are stored after tool.execute() runs. If execution throws, the DB ends up with a tool result row but no matching assistant row, corrupting thread replay for Claude.
2. Empty apiKey fallback (server.ts ~line 499) — apiKey ?? '' means a misconfigured provider silently constructs a working handler that returns 401 on every LLM call instead of returning undefined to disable the agent.
3. ApiClient with undefined apiUrl/apiKey (server.ts ~line 503) — self-hosted instances without apiUrl set will get silent failures on run_sweep and all GSC tools.
4. Orphaned messages on thread delete (agent.ts ~line 220) — ON DELETE CASCADE only fires if PRAGMA foreign_keys = ON, which is not guaranteed.
5. Unbounded message field (agent.ts ~line 158) — no maxLength on the message body; a single large payload can rack up LLM token costs.

Security:

• dns.resolve6 catch-all silently swallows errors (sitemap-parser.ts) — not exploitable but could incorrectly block IPv6-only hosts.
• Missing message length limit (covered above under Bugs).

Testing gap:

• ~830 lines of new agent code ship with zero unit tests. The loop's history-windowing, maxSteps fallback, and JSON recovery paths are all critical and unverified.

Performance:

• getTimeline has an N+1 query pattern; getHistory already demonstrates the correct bulk-fetch approach.

What's done well ✅

• The SSRF hardening in sitemap-parser.ts is thorough: DNS resolution, IPv4/IPv6 loopback, link-local, ULA, and IPv4-mapped IPv6 addresses are all covered, with tests.
• History windowing (newest-N-ascending subquery) is the right approach and well-commented.
• Provider abstraction is clean — adding a new LLM is a one-function addition in llm.ts.
• Malformed JSON recovery in convertToClaudeMessages is a good defensive touch.
• DB schema with ON DELETE CASCADE + composite index on (thread_id, created_at) is solid.

Overall assessment: NEEDS_WORK on the tool-call persistence bug and the ApiClient/apiKey issues before this is safe to merge.

This review was generated by an AI agent. Please verify all suggestions.

[arberx]

Unsure that this is necessary in Canonry at the moment.

The real power of canonry is leveraged through a "openclaw" type agent that has full accessibility to the host operating system with a well constructed memory.

This agent UI feels like any other agent UI. Not a fan so far.

[arberx]

Missing error handling on sendAgentMessage: If this call throws (e.g. network error, 4xx/5xx), the exception propagates uncaught and the polling loop below never runs — which is fine. However, if the server accepts the message but never transitions out of 'processing', the loop silently times out and returns an empty string (see line 62–80). A tighter pattern would be to await this, and then check the thread status before entering the poll loop.

[arberx]

Silent timeout — no error signal when the agent takes >3 minutes: When i reaches 120 (120 × 1500ms = 3 min), the loop exits without setting process.exitCode or printing an error. The caller receives an empty response string and exit code 0, which looks like success.

// After the loop:
if (!response) {
  console.error('\nTimed out waiting for agent response (3 min).')
  process.exitCode = 1
  return
}

[arberx]

DNS rebinding / TOCTOU: The DNS check in validateSitemapUrl (lines 66–88) happens before fetch(url). A malicious DNS server can return a public IP during validation, then switch to a private IP for the actual fetch request — this is a classic DNS rebinding attack.

Full mitigation requires resolving the hostname to an IP, asserting it's public, then connecting to that specific IP directly (e.g. by passing a custom agent to fetch that pins the resolved IP). The current approach significantly raises the bar vs. the old static regex check, but it is not bulletproof. Worth adding a comment documenting this known limitation so it's not mistaken for a complete fix.

[arberx]

Security: systemTools defaults to false — good. Consider adding a prominent warning when it's enabled.

When agent.systemTools: true, the built-in agent gains shell execution, file I/O, and HTTP request capabilities. Since the agent operates on user-supplied message content, an adversarial input could abuse these tools. At minimum, log a startup warning when systemTools is true so operators notice, and document clearly in the config schema that this is a dangerous option.

[arberx]

🤖 Automated Review — PR #74 (incremental: new commits since last review)

Summary: Solid agent foundation. The LLM loop, tool system, and CLI commands are well-structured. A few issues flagged inline:

Severity	Finding	File
🟠 Bug	Silent timeout — loop exits with exitCode=0 + empty response after 3 min	commands/agent.ts:83
🟠 Bug	--wait polls indexingState (wrong field — means allowed, not indexed)	commands/google.ts (already in main)
🔴 Security	DNS rebinding TOCTOU in validateSitemapUrl	sitemap-parser.ts:110
🟡 Robustness	sendAgentMessage failure not linked to poll-loop lifecycle	commands/agent.ts:58
🟡 Security	systemTools: true silently grants shell/file/network to agent	server.ts:509

The --wait / INDEXING_ALLOWED bug is already on main — worth a hotfix or follow-up issue independent of this PR.