coleam00/Archon · error

Failed to clone ${owner}/${repo}: ${unknownMsg}

Error message

Failed to clone ${owner}/${repo}: ${unknownMsg}

What it means

The catch-all clone failure path in ensureRepoReady: when the clone error code is neither 'not_a_repo' nor 'permission_denied', the adapter surfaces the underlying error's message (or 'unknown error') wrapped with the owner/repo. Typical underlying causes are network failures, invalid remote URL, or git binary problems.

Source

Thrown at packages/adapters/src/community/forge/gitea/adapter.ts:558

    const cloneResult = await cloneRepository(repoUrl, toRepoPath(repoPath), {
      token: process.env.GITEA_TOKEN,
    });

    if (!cloneResult.ok) {
      getLog().error({ owner, repo, repoPath, error: cloneResult.error }, 'repo_clone_failed');

      if (cloneResult.error.code === 'not_a_repo') {
        throw new Error(
          `Repository ${owner}/${repo} not found or is private. Check repository access.`
        );
      }
      if (cloneResult.error.code === 'permission_denied') {
        throw new Error(
          `Authentication failed for ${owner}/${repo}. Check GITEA_TOKEN permissions.`
        );
      }
      const unknownMsg = (cloneResult.error as { message?: string }).message ?? 'unknown error';
      throw new Error(`Failed to clone ${owner}/${repo}: ${unknownMsg}`);
    }

    await addSafeDirectory(toRepoPath(repoPath));
  }

  /**
   * Auto-detect and load commands from .archon/commands/ (or configured folder)
   */
  private async autoDetectAndLoadCommands(repoPath: string, codebaseId: string): Promise<void> {
    const commandFolders = getCommandFolderSearchPaths();

    for (const folder of commandFolders) {
      try {
        const fullPath = join(repoPath, folder);
        await access(fullPath);

        const files = (await readdir(fullPath)).filter(f => f.endsWith('.md'));
        if (files.length === 0) continue;

View on GitHub (pinned to 0773b97458)

Solutions

  1. Read the embedded unknownMsg for the root cause (DNS, TLS, network) and fix accordingly.
  2. Test reachability: git ls-remote <gitea-url>/owner/repo.git from the adapter host.
  3. Verify the configured Gitea base URL is correct (scheme, host, port).
  4. If the message is 'unknown error', enable adapter debug logging to capture the raw clone failure, then retry.

Example fix

// before
giteaUrl: "http://gitea.internal:3000" // host unreachable from adapter

// after
giteaUrl: "https://gitea.internal" // reachable, valid TLS
# verify: git ls-remote https://gitea.internal/owner/repo.git
Defensive patterns

Strategy: retry

Validate before calling

// check remote reachability before handling webhooks
const { code } = Bun.spawnSync(['git', 'ls-remote', `${giteaUrl}/${owner}/${repo}.git`]);
if (code !== 0) throw new Error('Gitea remote unreachable from adapter host');

Try / catch

try {
  await adapter.handleWebhook(update);
} catch (err) {
  const m = String(err);
  if (m.startsWith('Failed to clone') && !m.includes('not found') && !m.includes('Authentication failed')) {
    await sleep(2000); return adapter.handleWebhook(update); // transient network: one retry
  }
  throw err;
}

Prevention

When it happens

Trigger: handleWebhook -> ensureRepoReady cloning while DNS/network to the Gitea host is down, the remote URL is malformed (bad scheme or path), the git credential/transport returns an unexpected error, or cloneResult.error carries no message at all (then 'unknown error' is shown).

Common situations: Self-hosted Gitea behind a firewall/proxy unreachable from the adapter host; TLS certificate verification failure; wrong instance URL in config; disk full mid-clone.

Related errors


AI-assisted analysis of coleam00/Archon@0773b97458 (2026-09-01). Data as JSON: /api/errors/9fe67b851dcb357b. Report an issue: GitHub.