Yeachan-Heo/oh-my-codex · critical · Error

Unknown adapt target: ${target}

Error message

Unknown adapt target: ${target}

What it means

Thrown when the native archive binary selected for extraction exists in the archive but reports a size of zero bytes. The library validates that the chosen candidate is non-empty before streaming it, because a 0-byte binary is almost certainly a corrupted, truncated, or placeholder archive entry and would produce an unusable executable.

Source

Thrown at src/adapt/index.ts:87

			? `${selection.testSpecPaths.length} matching test spec artifact(s) linked.`
			: "PRD detected, but no matching test spec artifact was found for its slug.";

	return {
		prdPath: selection.prdPath,
		testSpecPaths: selection.testSpecPaths,
		deepInterviewSpecPaths: selection.deepInterviewSpecPaths,
		summary: testSpecSummary,
	};
}

export function buildAdaptEnvelope(
	cwd: string,
	target: AdaptTarget,
	now = new Date(),
): AdaptEnvelope {
	const descriptor = getAdaptTargetDescriptor(target);
	if (!descriptor) {
		throw new Error(`Unknown adapt target: ${target}`);
	}

	const paths = resolveAdaptPaths(cwd, target);
	const planning = buildAdaptPlanningLink(cwd);

	if (target === "openclaw") {
		return buildOpenClawEnvelope(paths, planning, descriptor.capabilities, now);
	}

	return {
		schemaVersion: ADAPT_SCHEMA_VERSION,
		generatedAt: toIsoTimestamp(now),
		target,
		displayName: descriptor.displayName,
		summary: descriptor.summary,
		adapterPaths: paths,
		planning,
		capabilities: descriptor.capabilities,

View on GitHub (pinned to 3ad79a8a6f)

Solutions

1. Re-download the archive from the release source and verify its SHA/checksum before retrying
2. Inspect the archive (unzip -l / tar -tvf) to confirm the binary entry has non-zero size; if zero, the upstream asset is broken — rebuild or re-upload it
3. If you maintain the release pipeline, ensure binaries are actually built and packed (not LFS pointers or empty stubs) before publishing
4. Add a size/checksum verification step in CI after fetching native assets

Example fix

// before
const bin = await archiveBinary(archivePath, 'mytool'); // throws archive_binary_empty

// after
const entries = await inspectNativeArchive(archivePath);
const entry = entries.find(e => e.normalizedName.endsWith('mytool'));
if (!entry || entry.size <= 0) throw new Error('archive corrupt, re-fetch release asset');
const bin = await archiveBinary(archivePath, 'mytool');

const entries = await inspectNativeArchive(archivePath);
const entry = entries.find(e => e.type === 'file' && e.normalizedName.endsWith('/mytool'));
if (!entry || entry.size <= 0) {
  await rm(archivePath, { force: true });
  throw new Error('archive corrupt: empty binary entry, re-fetch release asset');
}

const isNonEmptyEntry = (e: { type: string; size: number }): boolean => e.type === 'file' && e.size > 0;

try { await archiveBinary(p, 'mytool'); } catch (e) { if ((e as {code?:string}).code === 'archive_binary_empty') { await rm(p, {force:true}); /* re-download then retry once */ } else throw e; }

When it happens

Trigger: selectNativeArchiveBinary found exactly one matching entry (exact or wrapped name) but its size property is <= 0. Happens with corrupted/truncated downloads, archives packed with placeholder files (e.g. Git LFS pointer artifacts committed as empty), or zip entries whose central directory size field is zero.

Common situations: Downloading a release asset through a proxy that returns an empty file on auth failure; Git LFS-managed binaries committed without pulling LFS objects; interrupted curl/wget producing a partially-written zip; CI caches serving stale zero-byte artifacts.

Related errors

• native_agent_canonical_invalid
• archive_inspection_failed
• archive_format_unsupported
• invalid auth slot name: use 1-64 letters, numbers, '.', '_'
• (result.stderr || '').trim() || `git status failed for ${wor

AI-assisted analysis of Yeachan-Heo/oh-my-codex@3ad79a8a6f (2026-08-27). Data as JSON: /api/errors/cfcbb4f989ad4cac. Report an issue: GitHub.