fix: support native T3 executables during setup - #9
Conversation
|
Important
This repository does not receive automatic reviews because it has fewer than 10 stars. ⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Advanced Run ID: Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: ff27b4ff5a
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| const pkg = JSON.parse( | ||
| readFileSync(join(dirname(executable), "package.json"), "utf8"), | ||
| ); | ||
| if (pkg.name !== `@t3code/t3-${process.platform}-${process.arch}`) return; |
There was a problem hiding this comment.
Validate the target executable architecture independently
On Apple Silicon, setup can run under an x64 Node/Rosetta installation while the running T3 executable is the native arm64 package (or vice versa). process.arch describes the setup process rather than the inspected executable, so this exact package-name comparison rejects that otherwise valid local server and reports that no supported T3 instance was found. Accept the supported package architectures for the current platform or determine the target executable's architecture directly.
Useful? React with 👍 / 👎.
Problem
Setup reports "No supported running T3 instance found" for native T3 installations even when the server is running and the correct data directory is supplied. Native distributions launch
t3 serve; discovery treatsserveas a JavaScript entrypoint and fails to resolve it.Change
Recognize a running native executable by its platform package name and binary filename, retain the data-directory and loopback-origin checks, and invoke its credential commands directly. Scan the executable bytes for the installer's existing Codex launch-argument capability marker without decoding the binary as UTF-8.
Add regression coverage for native discovery, issuance, renewal, failed-verification revocation, unrelated packages, and mismatched data directories. The fixture copies Node to emulate the native executable's argument layout without adding a compiler or downloading T3 in CI.
Validation
npm test: 57 passed, two Windows-only tests skipped on Linux.npm run checkandnpm pack --dry-runpassed.0.0.41-nightly.20260914.1722: discovery, capability detection, credential issuance, and authenticated verification passed. The temporary credential was revoked afterward.Native macOS and Windows installations have not been manually verified.