Fix TrueForge UI port conflicts, Node 22 segfaults, and CRLF line endings - #17
Merged
Conversation
🤖 CodeAnt AI — Review Status
|
Thanks for using CodeAnt! 🎉We're free for open-source projects. if you're enjoying it, help us grow by sharing. Share on X · |
codeant-ai
Bot
added
the
size:M
|
Failed to generate code suggestions for PR |
PR Summary by QodoStabilize TrueForge on port 8790 with local WSL Node 22
AI Description
Diagram
High-Level Assessment
Files changed (11)
|
![codeant-ai[bot]](https://avatars.githubusercontent.com/in/646884?s=60&v=4){kind=small}
| # value so stale lines are replaced, never duplicated. | ||
| foreach ($key in @("TRUEFORGE_URL", "NEXT_PUBLIC_TRUEFORGE_URL")) { | ||
| $newVal = "${key}=http://${wslIp}:3000" | ||
| $newVal = "${key}=http://${wslIp}:8790" |
There was a problem hiding this comment.
Suggestion: The new per-key value check does not make the subsequent ^${key}= match multiline. When either variable exists below the first line of .env.local, the script fails to detect it, appends a second assignment, and leaves duplicate values that different consumers may resolve differently. Use a multiline-aware match or inspect the split lines consistently before appending. [api mismatch]
Severity Level: Major ⚠️
- ⚠️ Dashboard environment file retains conflicting TrueForge URLs.
- ⚠️ Restarted dashboard configuration may resolve stale endpoint values.
Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** scripts/start-all.ps1
**Line:** 130:130
**Comment:**
*Api Mismatch: The new per-key value check does not make the subsequent `^${key}=` match multiline. When either variable exists below the first line of `.env.local`, the script fails to detect it, appends a second assignment, and leaves duplicate values that different consumers may resolve differently. Use a multiline-aware match or inspect the split lines consistently before appending.
Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
Once fix is implemented, also check other comments on the same PR, and ask user if the user wants to fix the rest of the comments as well. if said yes, then fetch all the comments validate the correctness and implement a minimal fix
Code Review by Qodo
1. Checkout path is hard-coded
|
![qodo-code-review[bot]](https://avatars.githubusercontent.com/in/484649?s=60&v=4){kind=small}
|
|
||
| # Step 7: Start TrueForge | ||
| Write-Host "[7/7] Starting TrueForge in WSL..." -ForegroundColor Yellow | ||
| Start-Process powershell -ArgumentList "-NoExit", "-Command", "wsl -- bash -c 'cd `"/mnt/c/Users/adity/Documents/Mission Control/scripts/wsl`" && bash start-trueforge.sh'" |
There was a problem hiding this comment.
1. Checkout path is hard-coded 🐞 Bug ≡ Correctness
Step 7 always changes into one developer's /mnt/c/Users/adity/Documents/Mission Control checkout, so every clone at a different username, drive, or directory fails the cd and never starts TrueForge. This makes the advertised one-command startup unusable for a normal clean checkout.
Agent Prompt
## Issue description
The TrueForge startup command hard-codes one developer's WSL checkout path, so other clones cannot start.
## Issue Context
Use `$PSScriptRoot` and convert the resulting Windows path with `wslpath`, as the repository's other launcher already does.
## Fix Focus Areas
- start.ps1[80-83]
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
|
|
||
| # Step 7: Start TrueForge | ||
| Write-Host "[7/7] Starting TrueForge in WSL..." -ForegroundColor Yellow | ||
| Start-Process powershell -ArgumentList "-NoExit", "-Command", "wsl -- bash -c 'cd `"/mnt/c/Users/adity/Documents/Mission Control/scripts/wsl`" && bash start-trueforge.sh'" |
There was a problem hiding this comment.
2. Setup and launch differ 🐞 Bug ≡ Correctness
Steps 5–6 install Node and TrueForge specifically into the Ubuntu WSL distro, but Step 7 launches the default distro by omitting -d Ubuntu. When another distro is the default, startup runs where the installed runtime and package do not exist and TrueForge fails to launch.
Agent Prompt
## Issue description
The installer targets Ubuntu but the launcher targets whichever WSL distro is default.
## Issue Context
Use the same explicit distro for installation, detection, path conversion, and startup, or consistently use the default distro for all steps.
## Fix Focus Areas
- start.ps1[61-82]
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
Comment on lines
+65
to
+66
| Write-Host " Installing Node.js 22 in WSL (~/.local/node)..." | ||
| wsl -d Ubuntu -- bash -c 'mkdir -p ~/.local/node && curl -fsSL https://nodejs.org/dist/v22.14.0/node-v22.14.0-linux-x64.tar.gz | tar -xz -C ~/.local/node --strip-components=1' |
There was a problem hiding this comment.
5. Arm64 wsl downloads x64 🐞 Bug ☼ Reliability
The Windows setup unconditionally downloads the linux-x64 Node archive, which cannot run in an ARM64 WSL distribution. On Windows-on-ARM systems, the subsequent npm and TrueForge steps therefore fail instead of installing the matching ARM64 build.
Agent Prompt
## Issue description
The local Node installer always installs an x64 binary, including in ARM64 WSL.
## Issue Context
Detect `uname -m` inside the selected distro and map supported architectures to the corresponding Node archive, failing clearly for unsupported values.
## Fix Focus Areas
- start.ps1[65-67]
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
| echo "[1/6] Checking prerequisites..." | ||
| command -v docker >/dev/null 2>&1 || { echo "Error: docker is required. Install Docker Desktop."; exit 1; } | ||
| if command -v node >/dev/null 2>&1; then echo " - Node: $(node --version)"; else echo "Error: node 18+ is required."; exit 1; fi | ||
| if command -v node >/dev/null 2>&1; then echo " - Node: $(node --version)"; else echo "Error: node 22+ is required."; exit 1; fi |
There was a problem hiding this comment.
Suggestion: The prerequisite check only tests whether node exists, despite requiring Node 22+ in its error message and installing a runtime that depends on that version. Node 20 or older passes this check and setup proceeds until a later build or TrueForge invocation fails. Parse node --version and reject versions below 22 at the prerequisite boundary. [incorrect condition logic]
Severity Level: Major ⚠️
- ⚠️ Unsupported Node versions pass prerequisite validation.
- ❌ TrueForge startup may fail after setup work completes.
- ⚠️ Users receive delayed runtime errors instead of actionable validation.
Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** scripts/setup.sh
**Line:** 13:13
**Comment:**
*Incorrect Condition Logic: The prerequisite check only tests whether `node` exists, despite requiring Node 22+ in its error message and installing a runtime that depends on that version. Node 20 or older passes this check and setup proceeds until a later build or TrueForge invocation fails. Parse `node --version` and reject versions below 22 at the prerequisite boundary.
Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
Once fix is implemented, also check other comments on the same PR, and ask user if the user wants to fix the rest of the comments as well. if said yes, then fetch all the comments validate the correctness and implement a minimal fix| if command -v npx >/dev/null 2>&1; then | ||
| echo " Starting TrueForge in background..." | ||
| nohup npx @truefoundry/trueforge >/tmp/missioncontrol-trueforge.log 2>&1 & | ||
| nohup npx -y @truefoundry/trueforge >/tmp/missioncontrol-trueforge.log 2>&1 & |
There was a problem hiding this comment.
Suggestion: This direct startup path does not source .env or export its variables before invoking TrueForge. The setup script creates .env and documents OPENAI_API_KEY there, but the child process inherits only the shell environment, so a key configured in .env is invisible to TrueForge and the command can appear to start while model authentication fails. Source .env or start the repository launcher that already loads it. [incomplete implementation]
Severity Level: Major ⚠️
- ❌ Linux/macOS setup loses configured TrueForge credentials.
- ⚠️ TrueForge starts but model requests fail authentication.
- ⚠️ Users must manually export credentials or configure them again.
Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** scripts/setup.sh
**Line:** 75:75
**Comment:**
*Incomplete Implementation: This direct startup path does not source `.env` or export its variables before invoking TrueForge. The setup script creates `.env` and documents `OPENAI_API_KEY` there, but the child process inherits only the shell environment, so a key configured in `.env` is invisible to TrueForge and the command can appear to start while model authentication fails. Source `.env` or start the repository launcher that already loads it.
Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
Once fix is implemented, also check other comments on the same PR, and ask user if the user wants to fix the rest of the comments as well. if said yes, then fetch all the comments validate the correctness and implement a minimal fix| cd "$HOME" | ||
| export HOST=0.0.0.0 | ||
| exec npx -y @truefoundry/trueforge --port 3000 No newline at end of file | ||
| exec npx -y @truefoundry/trueforge No newline at end of file |
There was a problem hiding this comment.
Suggestion: The WSL setup installs @truefoundry/trueforge globally, but npx -y resolves the package through the npm package resolver rather than explicitly invoking that installed global binary. Consequently, startup still requires registry access and may select a different version or fail offline even after the prerequisite installation succeeded. Invoke the installed package/binary directly or make the network-dependent installation an explicit prerequisite. [api mismatch]
Severity Level: Major ⚠️
- ❌ Offline WSL startup can fail despite successful installation.
- ❌ TrueForge remains unavailable on port 8790.
- ⚠️ Dashboard agent interactions cannot reach the runtime.
Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** scripts/wsl/start-trueforge.sh
**Line:** 30:30
**Comment:**
*Api Mismatch: The WSL setup installs `@truefoundry/trueforge` globally, but `npx -y` resolves the package through the npm package resolver rather than explicitly invoking that installed global binary. Consequently, startup still requires registry access and may select a different version or fail offline even after the prerequisite installation succeeded. Invoke the installed package/binary directly or make the network-dependent installation an explicit prerequisite.
Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
Once fix is implemented, also check other comments on the same PR, and ask user if the user wants to fix the rest of the comments as well. if said yes, then fetch all the comments validate the correctness and implement a minimal fix|
|
||
| # Step 7: Start TrueForge | ||
| Write-Host "[7/7] Starting TrueForge in WSL..." -ForegroundColor Yellow | ||
| Start-Process powershell -ArgumentList "-NoExit", "-Command", "wsl -- bash -c 'cd `"/mnt/c/Users/adity/Documents/Mission Control/scripts/wsl`" && bash start-trueforge.sh'" |
There was a problem hiding this comment.
Suggestion: The launcher uses a checkout path belonging to one developer instead of deriving the repository location from $PSScriptRoot. On any other machine or clone location, WSL changes into a nonexistent directory and cannot find start-trueforge.sh, so TrueForge never starts. Resolve the Windows repository path dynamically and convert it to a WSL path. [api mismatch]
Severity Level: Critical 🚨
- ❌ TrueForge cannot start from ordinary clone locations.
- ❌ Windows one-click startup fails for other developers.
- ⚠️ Success output incorrectly reports TrueForge as starting.
Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** start.ps1
**Line:** 82:82
**Comment:**
*Api Mismatch: The launcher uses a checkout path belonging to one developer instead of deriving the repository location from `$PSScriptRoot`. On any other machine or clone location, WSL changes into a nonexistent directory and cannot find `start-trueforge.sh`, so TrueForge never starts. Resolve the Windows repository path dynamically and convert it to a WSL path.
Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
Once fix is implemented, also check other comments on the same PR, and ask user if the user wants to fix the rest of the comments as well. if said yes, then fetch all the comments validate the correctness and implement a minimal fix
CodeAnt Nitpicks1 code suggestion1. Failure responses disclose the internal TrueForge endpoint to unauthenticated webhook callers.Security · |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
User description
Automated PR to fix port conflicts and WSL execution issues.
CodeAnt-AI Description
Resolve TrueForge startup conflicts and align local setup with port 8790
What Changed
npxwhen neededImpact
✅ Fewer local port conflicts✅ More reliable Windows and WSL startup✅ Clearer setup instructions💡 Usage Guide
Checking Your Pull Request
Every time you make a pull request, our system automatically looks through it. We check for security issues, mistakes in how you're setting up your infrastructure, and common code problems. We do this to make sure your changes are solid and won't cause any trouble later.
Talking to CodeAnt AI
Got a question or need a hand with something in your pull request? You can easily get in touch with CodeAnt AI right here. Just type the following in a comment on your pull request, and replace "Your question here" with whatever you want to ask:
This lets you have a chat with CodeAnt AI about your pull request, making it easier to understand and improve your code.
Example
Preserve Org Learnings with CodeAnt
You can record team preferences so CodeAnt AI applies them in future reviews. Reply directly to the specific CodeAnt AI suggestion (in the same thread) and replace "Your feedback here" with your input:
This helps CodeAnt AI learn and adapt to your team's coding style and standards.
Example
Retrigger review
Ask CodeAnt AI to review the PR again, by typing:
Check Your Repository Health
To analyze the health of your code repository, visit our dashboard at https://app.codeant.ai. This tool helps you identify potential issues and areas for improvement in your codebase, ensuring your repository maintains high standards of code health.