Add setup wizard for T3-scoped Codex MCP installation - #4
Conversation
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. |
|
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 |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 97e009adb8
ℹ️ 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".
| await exec("gh", ["auth", "status"], { | ||
| timeout: 15_000, | ||
| windowsHide: true, |
There was a problem hiding this comment.
Validate gh in the selected provider environment
gh auth status runs before the T3 instance and provider are selected, so it only validates the setup shell's environment. The installed MCP instead inherits the live T3 process and provider environment; when a desktop process has a restricted PATH, or a provider overrides HOME, GH_CONFIG_DIR, or authentication variables, setup can succeed even though every later GitHub poll fails to execute or authenticate gh. Run this prerequisite check under the environment that the selected Codex provider will actually supply.
Useful? React with 👍 / 👎.
| } catch (error) { | ||
| rollback(); | ||
| throw error; | ||
| } finally { | ||
| for (const lock of locks) rmSync(lock, { force: true }); |
There was a problem hiding this comment.
Keep configuration locks until verification finishes
These locks are removed when applyPlan returns, before runSetup performs credential and T3 verification. If setup B starts after setup A writes the files, B can see an idempotent plan and finish successfully; if A then fails verification, A's rollback still sees its expected bytes and restores the originals, erasing B's successful installation. Hold transaction ownership through verification, because the byte-equality rollback check cannot distinguish an overlapping installer that accepted the same contents.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: ba3d42396b
ℹ️ 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 override = environment.T3CODE_CODEX_LAUNCH_ARGS?.trim(); | ||
| const globalEnvironmentScope = | ||
| !!override && | ||
| !provider.environment.T3CODE_CODEX_LAUNCH_ARGS?.trim() && |
There was a problem hiding this comment.
Do not exempt provider overrides from global-scope checks
When the live T3 process has a process-wide T3CODE_CODEX_LAUNCH_ARGS that enables this server, adding the same override to the selected provider makes this condition false. Other enabled providers—particularly ones sharing the same Codex home—still inherit the process-wide value, so setup succeeds even though their fresh Codex sessions also enable the selected provider's MCP entry. Base this check on the raw process-wide value and require its removal and a T3 restart, unless every other affected provider is proven to mask it.
Useful? React with 👍 / 👎.
| }), | ||
| ); | ||
| } | ||
| let codexHome = values["codex-home"]; |
There was a problem hiding this comment.
Resolve explicit Codex homes against the caller's directory
When --codex-home is relative and the running T3 process has a different working directory from the setup shell, this raw value is later passed to planInstall, which resolves it against live.cwd. Setup consequently writes and records an unintended directory while the other path flags resolve relative to the caller. Expand this CLI-provided path before passing it into the plan.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: dc1e742aa3
ℹ️ 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".
| } | ||
| while (true) { | ||
| try { | ||
| await exec("gh", ["auth", "status"], { |
There was a problem hiding this comment.
Check only the active github.com authentication
When gh has an expired inactive account or an unused enterprise host, this rejects setup even though the active github.com account used by every poll is valid. The local gh auth status --help states that the unfiltered command tests every known account on every host and exits with 1 if any account has authentication issues, while src/github.ts pins requests to --hostname github.com; invoke the status check with --active --hostname github.com so unrelated credentials cannot block installation.
Useful? React with 👍 / 👎.
| const lock = `${e.path}.t3poll-lock`; | ||
| writeFileSync(lock, String(process.pid), { flag: "wx", mode: 0o600 }); | ||
| locks.push(lock); |
There was a problem hiding this comment.
Recover locks left by interrupted installers
If setup is killed, crashes, or the machine loses power after this exclusive file is created, the lock remains permanently. A later installation that still needs to edit that file always gets EEXIST, because neither applyPlan nor any startup path checks the recorded PID or removes stale locks; use a recoverable/advisory lock or validate stale ownership before rejecting the rerun.
Useful? React with 👍 / 👎.
Users currently configure Codex MCP and T3 launch arguments manually. Add
t3poll setupto discover a running T3 instance, select its Codex provider when needed, review the changes, and install T3-scoped MCP with a verified managed credential.Each T3/provider pair receives its own disabled MCP entry and launch enablement. Existing arguments are preserved; same-entry overrides, malformed arguments, and ineffective environment precedence produce actionable errors. Setup inherits the release channel from the package, supports dry runs and local builds before publication, creates private backups, checks for concurrent edits, and rolls back configuration if credential verification fails.
The original mock remains on
prototype/setup-wizard; this change replaces it with the real installer. npm publication and automatic worker handoff remain separate release work.Validation:
Before npm publication, try
npm run buildfollowed bynode dist/cli.js setup --runtime-path ./dist/cli.js. Add--dry-runto preview.