fix: add missing discordUserIds param and settings variable

[alanfeng99]

Summary

• config.ts: parseSettings was called with a discordUserIds argument from loadSettings/reloadSettings, but the function signature only accepted one parameter (raw). This caused a ReferenceError: discordUserIds is not defined at startup.
• runner.ts: execClaude destructured getSettings() directly into named variables but later referenced the full settings object for sessionTimeoutMs, causing a ReferenceError: settings is not defined during session bootstrap.

Both bugs are crash-on-start — the daemon cannot launch without these fixes.

Test plan

• Run bun run src/index.ts start --web and verify daemon starts without ReferenceError
• Verify Discord user ID parsing still works with snowflake IDs (large numbers)
• Verify sessionTimeoutMs setting is respected when configured

🤖 Generated with Claude Code

[Copilot]

Pull request overview

Fixes two startup-crashing ReferenceErrors in the daemon by aligning settings parsing and usage between config.ts and runner.ts.

Changes:

• Update parseSettings to accept and use a discordUserIds parameter (preserving large Discord snowflake IDs).
• Fix execClaude to keep a settings object (instead of only destructuring) so later references don’t crash.
• Reformat several long statements/arrays for readability and consistency.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
src/config.ts	Adds discordUserIds parameter to parseSettings and passes extracted snowflake IDs from raw JSON text.
src/runner.ts	Fixes settings reference in execClaude (and related call sites) and includes various formatting-only adjustments.

Comments suppressed due to low confidence (2)

src/config.ts:295

• sessionTimeoutMs is read from settings in runner.ts, but Settings/parseSettings() do not include this field, so any configured value in settings.json will be dropped during parsing and the timeout will always fall back to CLAUDE_TIMEOUT_MS. Consider adding sessionTimeoutMs (likely optional) to the Settings type, DEFAULT_SETTINGS, and parseSettings() with basic numeric validation so the setting is actually respected without relying on any casts downstream.

function parseSettings(
  raw: Record<string, any>,
  discordUserIds?: string[],
): Settings {
  const rawLevel = raw.security?.level;
  const level: SecurityLevel =
    typeof rawLevel === "string" && VALID_LEVELS.has(rawLevel as SecurityLevel)
      ? (rawLevel as SecurityLevel)
      : "moderate";

src/runner.ts:388

• timeoutMs is derived via (settings as any).sessionTimeoutMs, but Settings currently doesn’t define/parse sessionTimeoutMs, so this will never pick up a value from settings.json and the any cast masks the type error. Once sessionTimeoutMs is part of Settings/parseSettings, use the typed field here (and consider validating it’s a finite positive number before using it).

  const settings = getSettings();
  const securityArgs = buildSecurityArgs(settings.security);
  const { CLAUDECODE: _, ...cleanEnv } = process.env;
  const baseEnv = { ...cleanEnv } as Record<string, string>;
  const timeoutMs = (settings as any).sessionTimeoutMs || CLAUDE_TIMEOUT_MS;

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Same issue as above: timeoutMs uses (settings as any).sessionTimeoutMs, but the parsed Settings object doesn’t currently carry that field, so configured timeouts can’t take effect and the any cast hides the mismatch. Prefer a typed settings.sessionTimeoutMs once it’s added to Settings/parseSettings, with a sane fallback to CLAUDE_TIMEOUT_MS.

Suggested change

	const timeoutMs = (settings as any).sessionTimeoutMs || CLAUDE_TIMEOUT_MS;
	const timeoutMs = settings.sessionTimeoutMs ?? CLAUDE_TIMEOUT_MS;