[Critical] readOfflineLicense() returns the raw parsed JSON where customerId is nested under .payload, but formatStandaloneArchiveName() accesses license.customerId at the top level. This causes sanitizeArchiveComponent(undefined) to crash with TypeError: Cannot read properties of undefined (reading 'replace') whenever --license-file is used.

Either reuse the readOfflineLicense from create-standalone-package.js (which already flattens correctly and is exported), or flatten the return value:

— qwen-latest-series-invite-beta-v34 via Qwen Code /review

[Critical] crypto.verify() is called without try/catch. A corrupted or misformatted PEM key causes it to throw a raw OpenSSL error, which is NOT an OfflineLicenseError. In ensureOfflineLicense, the catch checks error instanceof OfflineLicenseError — the raw crypto error fails this check and is re-thrown, bypassing the interactive activation prompt entirely.

— qwen-latest-series-invite-beta-v34 via Qwen Code /review

[Critical] Non-atomic writeFile for the activation file. If the process crashes mid-write (OOM, SIGKILL, power loss), activation.json becomes corrupt. On next startup, readActivation throws "Offline activation file is invalid JSON." — which does NOT match the "Offline license is not activated." string in ensureOfflineLicense, so the interactive re-activation prompt is never triggered. The user is permanently stuck.

Write to a temp file and rename atomically:

— qwen-latest-series-invite-beta-v34 via Qwen Code /review

[Critical] Exact string match on error message creates fragile cross-package coupling. If the core package ever rephrases this message (even a punctuation change), the interactive activation flow silently breaks — the user sees a raw error instead of the activation prompt, with no compile-time or test-time signal.

Add a machine-readable code property to OfflineLicenseError and match on that instead:

// In core:
export class OfflineLicenseError extends Error {
  constructor(message: string, public readonly code: string) {
    super(message);
    this.name = 'OfflineLicenseError';
  }
}

// Here:
if (
  !(error instanceof OfflineLicenseError) ||
  error.code !== 'NOT_ACTIVATED' ||
  !interactive
) {
  throw error;
}

— qwen-latest-series-invite-beta-v34 via Qwen Code /review

[Critical] Zero log statements across the entire offline license flow (both core and CLI modules). Every failure — missing file, bad JSON, invalid signature, expired license, fingerprint mismatch, activation hash mismatch — surfaces only as a thrown error with a short string. When a customer reports "CLI won't start in our air-gapped environment," there is no diagnostic trail for the oncall engineer.

Add structured log lines at each decision point:

logger.info('offline-license: reading license file', { licensePath });
logger.info('offline-license: signature valid');
logger.info('offline-license: reading activation file', { activationPath });
logger.warn('offline-license: activation fingerprint mismatch');

— qwen-latest-series-invite-beta-v34 via Qwen Code /review

[Suggestion] export * re-exports signOfflineLicensePayload — a vendor-side signing function that requires a private key — in the client-facing public API of @qwen-code/qwen-code-core. Any downstream package can import and misuse it.

Replace with named exports excluding the signing function:

export {
  OFFLINE_LICENSE_VERSION,
  OFFLINE_ACTIVATION_VERSION,
  OfflineLicenseError,
  verifyOfflineLicense,
  activateOfflineLicense,
  type OfflineLicensePayload,
  type SignedOfflineLicense,
  type OfflineActivation,
  type OfflineLicenseStatus,
  type VerifyOfflineLicenseOptions,
  type ActivateOfflineLicenseOptions,
} from './license/offline-license.js';

— qwen-latest-series-invite-beta-v34 via Qwen Code /review

[Suggestion] @qwen-code/sdk@undefined with "License text not found." is a build-tooling artifact. The @undefined version and missing license text indicate the notices-generation tool failed to resolve the package. Fix the generation flow or remove this entry before shipping.

— qwen-latest-series-invite-beta-v34 via Qwen Code /review

[Suggestion] Activation file is written without explicit mode: 0o600. On multi-user systems, the default permissions (typically 0o644 via umask) allow other local users to read the activation file containing customerId, activationHashSha256, and licenseFingerprint.

— qwen-latest-series-invite-beta-v34 via Qwen Code /review

[Suggestion] Build-time readOfflineLicense validates structure (shape, field types) but never calls crypto.verify() to check the signature against the embedded public key. A license with a structurally valid but cryptographically bogus signature passes all build-time checks and is only rejected post-install by the customer.

Consider verifying the signature here before returning, so the build pipeline catches signing mistakes before delivery.

— qwen-latest-series-invite-beta-v34 via Qwen Code /review

[Suggestion] Interactive recovery only triggers for the exact "not activated" error. If the activation file is corrupted (invalid JSON from partial write), tampered (invalid shape), or stale (fingerprint mismatch after license renewal), the error is re-thrown with no recovery prompt. The user is stuck with an opaque error and must manually locate and delete the activation file.

Consider broadening the recovery condition to cover any OfflineLicenseError during verification, or at minimum detect these cases and suggest deleting the activation file.

— qwen-latest-series-invite-beta-v34 via Qwen Code /review

[Bug] cp and mkdir -p above have no error checking. If either fails (permission denied, disk full, locked file), the installer continues to create_source_json and prints log_success "Qwen Code standalone archive installed successfully." — the user sees a successful install, then gets a confusing Offline license file is missing. error on first launch with no connection to the installer failure.

The rest of install_standalone follows a strict if ! ... ; then log_error ...; return 1; fi pattern for critical operations (e.g., the mv of the wrapper script above). The new license copy should follow the same convention:

if ! mkdir -p "${qwen_home_dir}" || ! cp "${INSTALL_LIB_DIR}/offline-license/license.json" "${qwen_home_dir}/license.json"; then
    log_error "Failed to install offline license to ${qwen_home_dir}."
    return 1
fi

The same issue exists in install-qwen-with-source.bat at line 620, where copy /Y failures are silently ignored (the batch script uses if !ERRORLEVEL! NEQ 0 checks elsewhere but not here).

🔴 Critical — Missing });

This test block is never closed. The describe('loadCliConfig') closing }); is missing after this line, which breaks the build (tsc reports "Expected } but found it").

Fix: Add }); after this line:

    ).rejects.toThrow('Offline license file is missing.');
  });  // ← add this
  it('should prefer CLI fallback models over settings fallback models', ...

— qwen3.7-max via Qwen Code /review

🔴 Critical — No machine binding in activation

The activation record (OfflineActivation) is portable — it contains only customerId, activatedAt, activationHashSha256, and licenseFingerprint. Any machine that has the license file and the activation JSON can pass verification.

For a DRM feature targeting offline/air-gapped government customers, this means:

1. An activated license can be copied to unauthorized machines
2. There's no way to detect or prevent this

Suggestion: Bind activation to a machine fingerprint (hostname hash, machine-id, or MAC address hash) and verify it during verifyOfflineLicense. This doesn't need to be unbreakable — it raises the bar enough for the target deployment scenario.

— qwen3.7-max via Qwen Code /review

🔴 Critical — Public key sourced from user-editable settings

offlineLicense.publicKeyPem comes from settings.json, which the user controls. An attacker can:

1. Generate their own Ed25519 keypair
2. Set publicKeyPem to their public key in settings.json
3. Sign a forged license with their private key
4. Activate with the forged license

The entire DRM scheme is bypassed because the trust anchor (public key) is user-controlled.

Fix: The public key must come from a source the user cannot modify — embed it in the binary, read it from a signed package, or at minimum only accept it from the public-key.pem file deployed by the installer (not from settings).

— qwen3.7-max via Qwen Code /review

🔴 Critical — Three installer integration issues

1. Wrong installer modified. The license copy logic is added here (install-qwen-with-source.sh), but install-qwen-standalone.sh — the script actually invoked by runUnixInstaller in tests and by standalone deployments — has zero references to offline license files. License files are never deployed to $QWEN_HOME/ in the standalone path.

2. Stale activation on upgrade. This cp unconditionally overwrites license.json, but the existing activation.json in $QWEN_HOME/ retains the old licenseFingerprint. If the vendor issues a new signed license (different signature, same payload), the fingerprint changes → verifyOfflineLicense throws "activation does not match this license" → startup is blocked.

3. Enforcement never enabled. The installer copies license files but never sets security.offlineLicense.enabled = true in user settings. The feature is opt-in but the installer never opts in, so deployed licenses have no effect.

Fix: Add the same license copy logic to install-qwen-standalone.sh, handle the upgrade path (delete stale activation.json when license.json changes), and configure enabled: true during installation.

— qwen3.7-max via Qwen Code /review

🔴 Critical — ensureOfflineLicense happy path has no tests

This function orchestrates the core user-facing flow: try verify → catch "not activated" → prompt for activation code → activate. None of this is tested:

• Happy path (verify succeeds on first try)
• Activation flow (verify fails → prompt → activate succeeds)
• Non-interactive mode (verify fails → re-throw without prompting)
• Cancelled prompt (empty activation code)
• Fragile string match on error.message !== 'Offline license is not activated.'

This is the most complex new orchestration code in the PR and should have unit tests.

— qwen3.7-max via Qwen Code /review

🔴 Critical — readOfflineLicensePublicKey fallback untested

This function reads a PEM file synchronously with readFileSync and has a catch-all error handler that swallows all errors (including permission errors, not just missing files). No test exercises this path.

Additionally, the catch-all means a permission error on the key file produces the same message as a missing file, masking real issues.

— qwen3.7-max via Qwen Code /review

🟡 Suggestion — Fingerprint hashes the entire signed license, not just the payload

fingerprintLicense calls canonicalJson(license) on the full SignedOfflineLicense, which includes version and signature. If the vendor ever re-signs the same payload (e.g., after a version bump or key rotation), the fingerprint changes and existing activations break.

Consider hashing only the payload:

function fingerprintLicense(license: SignedOfflineLicense): string {
  return sha256Hex(canonicalJson(license.payload));
}

(Low confidence — this may be intentional to detect any modification.)

— qwen3.7-max via Qwen Code /review

🟡 Suggestion — Error messages lack diagnostic context

Pattern across this file: error messages state what failed but not the values that caused the failure. Examples:

• 'Offline license has expired.' — doesn't show the expiry date or current time
• 'Offline license seat count is invalid.' — doesn't show the actual value
• 'Offline license activation code is invalid.' — doesn't distinguish between wrong code and wrong license

Adding diagnostic values (not secrets) helps operators debug deployment issues:

throw new OfflineLicenseError(
  `Offline license has expired (expired at ${payload.expiresAt}).`,
);

— qwen3.7-max via Qwen Code /review

🟡 Suggestion — Array ordering not canonicalized

sortForCanonicalJson recursively sorts object keys but preserves array order. This means:

{ "features": ["agent-cli", "web-shell"] }
{ "features": ["web-shell", "agent-cli"] }

produce different canonical JSON strings and therefore different fingerprints. If two vendors (or two versions of the signing tool) emit features in different orders, the fingerprint won't match even though the payload is semantically identical.

Consider sorting arrays of primitives in sortForCanonicalJson:

if (Array.isArray(value)) {
  const sorted = value.map(sortForCanonicalJson);
  return sorted.every((v) => typeof v === 'string' || typeof v === 'number')
    ? sorted.sort()
    : sorted;
}

— qwen3.7-max via Qwen Code /review

🟡 Suggestion — OfflineLicenseStatus silently discarded

ensureOfflineLicense returns an OfflineLicenseStatus with customerId, seats, features, and expiresAt — but the return value is ignored here. None of this information is logged or made available to the user.

Consider at minimum logging the customer ID and expiry date at debug level, so operators can confirm which license is active:

const status = await ensureOfflineLicense({ ... });
debugLogger.debug(`Offline license active: ${status.customerId}, expires ${status.expiresAt}`);

— qwen3.7-max via Qwen Code /review