fix(setup): align PORT default on 3090 across .env.example, wizard, and JSDoc (#1152)#1271
Merged
Merged
Conversation
…nd JSDoc (#1152) The server's getPort() fallback changed from 3000 to 3090 in the Hono migration (#318), but .env.example, the setup wizard's generated .env, and the JSDoc describing the fallback were not updated — leaving three different sources of truth for "the default PORT." When the wizard writes PORT=3000 to ~/.archon/.env (which the Hono server loads with override: true, while Vite only reads repo-local .env), the two processes can land on different ports silently. That mismatch is the real mechanism behind the failure described in #1152. - .env.example: comment out PORT, document 3090 as the default - packages/cli/src/commands/setup.ts: wizard no longer writes PORT=3000 into the generated .env; fix the "Additional Options" note - packages/cli/src/commands/setup.test.ts: assert no bare PORT= line and the commented default is present - packages/core/src/utils/port-allocation.ts: fix stale JSDoc "default 3000" -> "default 3090" - deploy/.env.example: keep Docker default at 3000 (compose/Caddy target that) but annotate it so users don't copy it for local dev Single source of truth for the local-dev default is now basePort in port-allocation.ts.
📝 WalkthroughWalkthroughThe pull request updates the default server port from 3000 to 3090 across configuration examples, CLI setup generation, tests, and utility documentation. Changes include commented environment file entries with guidance and updated test expectations to reflect the new default behavior. Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
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.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@deploy/.env.example`:
- Line 49: The PORT line in the .env example contains an inline comment which
will be interpreted as part of the value by Docker Compose; change the env line
to a plain assignment "PORT=3000" (no trailing comment) and move the explanatory
guidance into its own comment line above (e.g., "# Docker deployment default
(compose/Caddy target :3000). For local dev omit PORT — server and Vite proxy
default to 3090."). Ensure references that rely on this value such as the
docker-compose port mapping "${PORT:-3000}:${PORT:-3000}" and the healthcheck
URL "http://localhost:${PORT:-3000}/api/health" will receive a clean numeric
PORT value.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: a04d075e-484e-43ef-b1e8-5ab9443ca7dc
📒 Files selected for processing (5)
.env.exampledeploy/.env.examplepackages/cli/src/commands/setup.test.tspackages/cli/src/commands/setup.tspackages/core/src/utils/port-allocation.ts
| # Optional | ||
| # ============================================ | ||
| PORT=3000 | ||
| PORT=3000 # Docker deployment default (the included compose/Caddy configs target :3000). For local dev (no Docker), omit PORT — server and Vite proxy both default to 3090. |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
Does Docker Compose env_file support inline # comments on the same line as KEY=VALUE, and in which version was this added?
💡 Result:
No, Docker Compose env_file does not support inline # comments on the same line as KEY=VALUE. env_file files are parsed as raw KEY=VALUE pairs by the Docker CLI, which only supports line comments starting with #, not inline comments. This matches the behavior of docker run --env-file, and changing it would break backward compatibility. Inline comments (e.g., KEY=VALUE # comment) are supported in the Compose CLI's .env file (used for variable interpolation in compose.yaml), but not in env_file. This distinction has been consistent, as confirmed in official docs and GitHub issues. The syntax rules for .env files explicitly describe inline comments with a space before # for unquoted values, but env_file uses a simpler parser without this feature.
Citations:
- 1: https://docs.docker.com/compose/env-file/
- 2: https://docs.docker.com/compose/environment-variables/env-file/
- 3: https://docs.docker.com/compose/how-tos/environment-variables/set-environment-variables/
- 4: https://docs.docker.com/compose/how-tos/environment-variables/variable-interpolation/
- 5: https://docs.docker.com/compose/env
- 6: https://docs.docker.com/compose/environment-variables/set-environment-variables
- 7: https://docs.docker.com/compose/how-tos/environment-variables/set-environment-variables
- 8:
--env-filedoesn't support inline comments docker/cli#4404 - 9: Inline comments in
.envdocker/compose#9025
🏁 Script executed:
fd -type f -name "docker-compose.yml" -o -name "docker-compose.yaml" | head -20Repository: coleam00/Archon
Length of output: 229
🏁 Script executed:
if git ls-files | grep -E "(docker-compose|compose)" | head -20; then :; fiRepository: coleam00/Archon
Length of output: 182
🏁 Script executed:
cat -n deploy/docker-compose.yml | head -100Repository: coleam00/Archon
Length of output: 1780
Inline comments on PORT=3000 will break Docker Compose env_file parsing.
Docker Compose's env_file parser does not support inline comments—the entire text after = is treated as the value, so a line like PORT=3000 # Docker deployment default... results in PORT being set to 3000 # Docker deployment default... instead of 3000. This breaks the ${PORT:-3000}:${PORT:-3000} port mapping and the http://localhost:${PORT:-3000}/api/health healthcheck. Move the guidance onto its own comment line:
🔒 Proposed fix
-PORT=3000 # Docker deployment default (the included compose/Caddy configs target :3000). For local dev (no Docker), omit PORT — server and Vite proxy both default to 3090.
+# Docker deployment default (the included compose/Caddy configs target :3000).
+# For local dev (no Docker), omit PORT — server and Vite proxy both default to 3090.
+PORT=3000📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| PORT=3000 # Docker deployment default (the included compose/Caddy configs target :3000). For local dev (no Docker), omit PORT — server and Vite proxy both default to 3090. | |
| # Docker deployment default (the included compose/Caddy configs target :3000). | |
| # For local dev (no Docker), omit PORT — server and Vite proxy both default to 3090. | |
| PORT=3000 |
🧰 Tools
🪛 dotenv-linter (4.0.0)
[warning] 49-49: [ValueWithoutQuotes] This value needs to be surrounded in quotes
(ValueWithoutQuotes)
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@deploy/.env.example` at line 49, The PORT line in the .env example contains
an inline comment which will be interpreted as part of the value by Docker
Compose; change the env line to a plain assignment "PORT=3000" (no trailing
comment) and move the explanatory guidance into its own comment line above
(e.g., "# Docker deployment default (compose/Caddy target :3000). For local dev
omit PORT — server and Vite proxy default to 3090."). Ensure references that
rely on this value such as the docker-compose port mapping
"${PORT:-3000}:${PORT:-3000}" and the healthcheck URL
"http://localhost:${PORT:-3000}/api/health" will receive a clean numeric PORT
value.
Collaborator
PR Review Summary (multi-agent)Reviewed with Critical IssuesNone. Important Issues (2 found)
Suggested replacement for // PORT is intentionally omitted so both the server and Vite proxy independently default
// to 3090, keeping them in sync regardless of which .env files each process reads.Suggestions (4 found)
Strengths
Documentation IssuesNone — independent scan of VerdictNEEDS MINOR FIXES — the CLAUDE.md comment-rule violations (two Recommended Actions
|
Wirasm
added a commit
that referenced
this pull request
Apr 17, 2026
Applies the CLAUDE.md comment rule ("don't embed paths/callers that rot
as the codebase evolves") flagged by the PR #1271 review to the Pi
provider's inline comments.
Three spots in the merged Pi code embed `packages/.../provider.ts:N-M`
line ranges pointing at the Claude and Codex providers. These ranges
will drift the moment those files change — the Claude auth-merge
pattern's line numbers are already off-by-a-few in some local branches.
Keep the conceptual cross-reference ("mirrors Claude's process-env +
request-env merge pattern", "matches the Codex provider's fallback
pattern for the same condition") — that's the load-bearing part of the
comment — drop the fragile line numbers and file paths.
Same treatment for the upstream Pi auth-storage.ts:424-485 reference,
which points at a specific line range in a moving dependency.
No behavior change; comment-only refactor.
1 task
Wirasm
added a commit
that referenced
this pull request
Apr 17, 2026
…nts (#1275) Applies the CLAUDE.md comment rule ("don't embed paths/callers that rot as the codebase evolves") flagged by the PR #1271 review to the Pi provider's inline comments. Three spots in the merged Pi code embed `packages/.../provider.ts:N-M` line ranges pointing at the Claude and Codex providers. These ranges will drift the moment those files change — the Claude auth-merge pattern's line numbers are already off-by-a-few in some local branches. Keep the conceptual cross-reference ("mirrors Claude's process-env + request-env merge pattern", "matches the Codex provider's fallback pattern for the same condition") — that's the load-bearing part of the comment — drop the fragile line numbers and file paths. Same treatment for the upstream Pi auth-storage.ts:424-485 reference, which points at a specific line range in a moving dependency. No behavior change; comment-only refactor.
ztech-gthb
pushed a commit
to ztech-gthb/Archon
that referenced
this pull request
Apr 18, 2026
…nts (coleam00#1275) Applies the CLAUDE.md comment rule ("don't embed paths/callers that rot as the codebase evolves") flagged by the PR coleam00#1271 review to the Pi provider's inline comments. Three spots in the merged Pi code embed `packages/.../provider.ts:N-M` line ranges pointing at the Claude and Codex providers. These ranges will drift the moment those files change — the Claude auth-merge pattern's line numbers are already off-by-a-few in some local branches. Keep the conceptual cross-reference ("mirrors Claude's process-env + request-env merge pattern", "matches the Codex provider's fallback pattern for the same condition") — that's the load-bearing part of the comment — drop the fragile line numbers and file paths. Same treatment for the upstream Pi auth-storage.ts:424-485 reference, which points at a specific line range in a moving dependency. No behavior change; comment-only refactor.
ztech-gthb
pushed a commit
to ztech-gthb/Archon
that referenced
this pull request
Apr 18, 2026
…nd JSDoc (coleam00#1152) (coleam00#1271) The server's getPort() fallback changed from 3000 to 3090 in the Hono migration (coleam00#318), but .env.example, the setup wizard's generated .env, and the JSDoc describing the fallback were not updated — leaving three different sources of truth for "the default PORT." When the wizard writes PORT=3000 to ~/.archon/.env (which the Hono server loads with override: true, while Vite only reads repo-local .env), the two processes can land on different ports silently. That mismatch is the real mechanism behind the failure described in coleam00#1152. - .env.example: comment out PORT, document 3090 as the default - packages/cli/src/commands/setup.ts: wizard no longer writes PORT=3000 into the generated .env; fix the "Additional Options" note - packages/cli/src/commands/setup.test.ts: assert no bare PORT= line and the commented default is present - packages/core/src/utils/port-allocation.ts: fix stale JSDoc "default 3000" -> "default 3090" - deploy/.env.example: keep Docker default at 3000 (compose/Caddy target that) but annotate it so users don't copy it for local dev Single source of truth for the local-dev default is now basePort in port-allocation.ts.
joaobmonteiro
pushed a commit
to joaobmonteiro/Archon
that referenced
this pull request
Apr 26, 2026
…nts (coleam00#1275) Applies the CLAUDE.md comment rule ("don't embed paths/callers that rot as the codebase evolves") flagged by the PR coleam00#1271 review to the Pi provider's inline comments. Three spots in the merged Pi code embed `packages/.../provider.ts:N-M` line ranges pointing at the Claude and Codex providers. These ranges will drift the moment those files change — the Claude auth-merge pattern's line numbers are already off-by-a-few in some local branches. Keep the conceptual cross-reference ("mirrors Claude's process-env + request-env merge pattern", "matches the Codex provider's fallback pattern for the same condition") — that's the load-bearing part of the comment — drop the fragile line numbers and file paths. Same treatment for the upstream Pi auth-storage.ts:424-485 reference, which points at a specific line range in a moving dependency. No behavior change; comment-only refactor.
joaobmonteiro
pushed a commit
to joaobmonteiro/Archon
that referenced
this pull request
Apr 26, 2026
…nd JSDoc (coleam00#1152) (coleam00#1271) The server's getPort() fallback changed from 3000 to 3090 in the Hono migration (coleam00#318), but .env.example, the setup wizard's generated .env, and the JSDoc describing the fallback were not updated — leaving three different sources of truth for "the default PORT." When the wizard writes PORT=3000 to ~/.archon/.env (which the Hono server loads with override: true, while Vite only reads repo-local .env), the two processes can land on different ports silently. That mismatch is the real mechanism behind the failure described in coleam00#1152. - .env.example: comment out PORT, document 3090 as the default - packages/cli/src/commands/setup.ts: wizard no longer writes PORT=3000 into the generated .env; fix the "Additional Options" note - packages/cli/src/commands/setup.test.ts: assert no bare PORT= line and the commented default is present - packages/core/src/utils/port-allocation.ts: fix stale JSDoc "default 3000" -> "default 3090" - deploy/.env.example: keep Docker default at 3000 (compose/Caddy target that) but annotate it so users don't copy it for local dev Single source of truth for the local-dev default is now basePort in port-allocation.ts.
5 tasks
prospapledge88
added a commit
to prospapledge88/Archon
that referenced
this pull request
May 5, 2026
* fix(core/test): split connection.test.ts from DB-test batch to avoid mock pollution (coleam00#1269) messages.test.ts uses mock.module('./connection', ...) at module-load time. Per CLAUDE.md:131 (Bun issue oven-sh/bun#7823), mock.module() is process- global and irreversible. When Bun pre-loads all test files in a batch, the mock shadows the real connection module before connection.test.ts runs, causing getDatabaseType() to always return the mocked value regardless of DATABASE_URL. Move connection.test.ts into its own `bun test` invocation immediately after postgres.test.ts (which runs alone) and before the big DB/utils/ config/state batch that contains messages.test.ts. This follows the same isolation pattern already used for command-handler, clone, postgres, and path-validation tests. * fix(setup): align PORT default on 3090 across .env.example, wizard, and JSDoc (coleam00#1152) (coleam00#1271) The server's getPort() fallback changed from 3000 to 3090 in the Hono migration (coleam00#318), but .env.example, the setup wizard's generated .env, and the JSDoc describing the fallback were not updated — leaving three different sources of truth for "the default PORT." When the wizard writes PORT=3000 to ~/.archon/.env (which the Hono server loads with override: true, while Vite only reads repo-local .env), the two processes can land on different ports silently. That mismatch is the real mechanism behind the failure described in coleam00#1152. - .env.example: comment out PORT, document 3090 as the default - packages/cli/src/commands/setup.ts: wizard no longer writes PORT=3000 into the generated .env; fix the "Additional Options" note - packages/cli/src/commands/setup.test.ts: assert no bare PORT= line and the commented default is present - packages/core/src/utils/port-allocation.ts: fix stale JSDoc "default 3000" -> "default 3090" - deploy/.env.example: keep Docker default at 3000 (compose/Caddy target that) but annotate it so users don't copy it for local dev Single source of truth for the local-dev default is now basePort in port-allocation.ts. * fix(providers/claude): use || instead of ?? in hasExplicitTokens to handle empty-string env vars (coleam00#1028) Closes coleam00#1027 * chore(deps): bump claude-agent-sdk to 0.2.121, codex-sdk to 0.125.0 (coleam00#1460) Both SDKs were ~30 patch releases behind. Validation suite passes (type-check, lint, format, tests across all 10 packages) without code changes. The only sustained Claude SDK behavior change in the range — v0.2.111's options.env overlay/replace flap, since reverted to overlay — is a no-op for Archon, which already passes { ...process.env } as the SDK env. * fix(cli): lazy-import bundled skill files so non-setup commands don't crash on missing source (coleam00#1394) The 18 top-level `import … with { type: 'text' }` statements in `bundled-skill.ts` resolve at module load. For `bun build --compile` that's build time, so the binary embeds the strings and works regardless of any on-disk skill files. For `bun link` (linked-source) installs that's every `archon` invocation — including `archon --help`, which doesn't even use the skill content. If any of the 18 source files are missing or moved, the import fails and the CLI cannot start at all. The skill content is data the binary deploys via `archon setup`, not data the CLI needs at runtime. There's only one consumer in production code: `copyArchonSkill()` in `setup.ts`. Moving the import into that function as a dynamic import preserves the compiled-binary behavior (Bun's bundler statically analyses literal-string `import()` and embeds the chunk — verified by grepping the SKILL.md frontmatter out of a freshly compiled binary) while making the linked-source install resilient: only `archon setup` triggers the bundled-skill module load now. Verified: a known skill string appears in the compiled binary 1×, and `archon --help` no longer needs the source files to start. `copyArchonSkill()` becomes async because the dynamic import is a Promise. The single production call site is already in an async function and gets an `await`. The four `setup.test.ts` cases become async too. * fix(claude): stop passing --no-env-file to native binary in dev mode (coleam00#1461) * fix(claude): stop passing --no-env-file to native binary in dev mode The Claude Agent SDK switched from shipping `cli.js` inside the package to per-platform native binaries via optional deps somewhere in the 0.2.x series. As of 0.2.121 there is no `cli.js` in the SDK package; dev mode resolves to `@anthropic-ai/claude-agent-sdk-darwin-arm64/claude` (Mach-O). That native binary rejects `--no-env-file` with `error: unknown option '--no-env-file'` and the subprocess exits 1. `shouldPassNoEnvFile` was returning true on `cliPath === undefined` on the assumption that "dev mode = JS executable run via Bun". That assumption is dead. Tighten the predicate to only return true on an explicit `.js` suffix, so we only emit the flag when the SDK is going to spawn a Bun-runnable script. CWD `.env` leak protection is unaffected. `stripCwdEnv()` in `@archon/paths` (coleam00#1067) deletes Bun-auto-loaded `.env`/`.env.local`/ `.env.development`/`.env.production` keys from `process.env` at every Archon entry point before any subprocess is spawned. The native Claude binary does not auto-load `.env` from its cwd either. `--no-env-file` was belt-and-suspenders for the JS-via-Bun case only. Verified end-to-end with a sentinel: added a unique `ARCHON_LEAK_SENTINEL_$$` to Archon's `.env`, ran e2e-claude-smoke with a bash probe checking the subprocess env. stderr shows `[archon] stripped 23 keys from /Users/rasmus/Projects/cole/Archon (.env, .env.local)` — sentinel was deleted. Bash node prints `PASS: simple='4', no sentinel leak`. Workflow completes cleanly, no `--no-env-file` rejection from the SDK binary. bun run validate: green across all 10 packages. * fix(claude): address review on coleam00#1461 (stale docs + test gaps) Critical: file-level JSDoc at provider.ts:18 still claimed dev mode resolves cli.js. Updated to reflect SDK 0.2.x's switch to per-platform native binaries. Important: security.md still listed --no-env-file as item 2 of target-repo .env isolation. Scoped that bullet to legacy Bun-runnable JS entry points and called out that native binaries don't auto-load .env from cwd. Added an Unreleased Fixed entry to CHANGELOG.md. Updated binary-resolver.ts JSDoc title that referenced cli.js. Polish: widened the predicate to accept .mjs and .cjs (also Bun-runnable JS — matches the SDK's own internal extension list). Dropped the redundant `passesNoEnvFile` log field that mirrored `isJsExecutable`. Added unit cases for .mjs/.cjs (now true) and .ts/.tsx/.jsx (deliberately false — never SDK entry points). Added an integration test that mocks resolveClaudeBinaryPath to return a .js path and asserts executableArgs: ['--no-env-file'] flows through buildBaseClaudeOptions all the way to the SDK call — catches future regressions in the conditional spread. bun run validate: green across all 10 packages. * fix(orchestrator): clear stale session ID on error_during_execution to prevent infinite failure loop (coleam00#1294) * fix(orchestrator): clear stale session ID on error_during_execution to prevent infinite failure loop When a Claude API session expires (e.g. after container restart), the orchestrator persists the new (failed) session ID from the error result, causing every subsequent message in that conversation to hit the same error — an infinite failure loop. Fix: on error_during_execution result, set assistant_session_id to NULL instead of persisting the failed session ID. The next message starts a fresh session with full context rebuilt from the DB. Conversation history is unaffected since it lives in remote_agent_messages, independent of the Claude session. Changes: - updateSession() and tryPersistSessionId() now accept string | null - Both handleStreamMode and handleBatchMode clear session ID on error_during_execution Fixes coleam00#1280 * test(orchestrator): add stale session clearing tests + address review feedback Co-Authored-By: Claude Opus 4 (1M context) <noreply@anthropic.com> Signed-off-by: kagura-agent <kagura.agent.ai@gmail.com> --------- Signed-off-by: kagura-agent <kagura.agent.ai@gmail.com> Co-authored-by: Claude Opus 4 (1M context) <noreply@anthropic.com> * fix(claude): honor CLAUDE_BIN_PATH in dev mode for libc-mismatch hosts (coleam00#1481) * fix(claude): honor CLAUDE_BIN_PATH in dev mode for libc-mismatch hosts The Claude Agent SDK auto-resolves its bundled native binary in [linux-x64-musl, linux-x64] order. On glibc Linux hosts (Ubuntu/Debian/ Fedora), Bun installs both via optionalDependencies and the musl variant is picked first; its ELF interpreter (/lib/ld-musl-x86_64.so.1) does not exist on glibc, so spawn fails and the SDK reports a misleading "binary not found" — the file is on disk, the loader is not. The documented escape hatch CLAUDE_BIN_PATH was dead code in dev mode: the resolver early-returned undefined when BUNDLED_IS_BINARY=false before ever reading the env var. The only workaround was patching node_modules. Move the env-var block above the BUNDLED_IS_BINARY return. Config-file path stays binary-mode-only — it's per-repo, not per-machine; env is the right knob for libc mismatches. Behavior preserved: - env unset → unchanged (undefined in dev, autodetect/throw in binary) - env set + file exists → resolved (was binary-only; now also dev) - env set + file missing → clear error (was binary-only; now also dev) Closes coleam00#1474 * chore(claude): address CodeRabbit review on coleam00#1481 - CHANGELOG entry under [Unreleased] / Fixed describing the dev-mode CLAUDE_BIN_PATH escape hatch (previously ignored). Notes that config-file path remains binary-mode-only and that env-loading + target-repo .env isolation are unchanged downstream. - Empty-string test pinning that CLAUDE_BIN_PATH='' falls through to undefined rather than throwing — protects against a future predicate typo that would treat empty as "set". - One-line note in ai-assistants.md "Binary path configuration" section pointing dev-mode users at the env-var override for the glibc/musl mismatch case. Skipped from the review: - The other two docs-page rewrites (configuration.md / troubleshooting.md): the error message itself names CLAUDE_BIN_PATH, and coleam00#1474 documents the use case publicly. One mention in ai-assistants.md is enough for discovery. - Type-style consistency tweaks in the test file: pure bikeshed. * fix(deps): bump hono to ^4.12.16 and @hono/node-server to ^1.19.13 (closes coleam00#1484) (coleam00#1499) * fix(orchestrator): create ~/.archon/workspaces before AI provider spawn (coleam00#1529) * fix(orchestrator): create ~/.archon/workspaces before AI provider spawn On a fresh install, ~/.archon/workspaces doesn't exist yet. The orchestrator passes that path as cwd to the AI provider, which calls spawn() — which raises ENOENT. The error is then misclassified as "binary not found" in the friendly-error path, surfacing as an incorrect "Claude binary not found" message. Add ensureArchonWorkspacesPath() in @archon/paths that mkdir -p's the directory and returns the path. Use it at the orchestrator's spawn-cwd site so the directory is guaranteed to exist before spawn(). Other call sites of getArchonWorkspacesPath() (workflow discovery, path-prefix comparisons) only consume the path string and don't need the directory to exist; they keep using the pure getter. Closes coleam00#1528 * test(orchestrator): assert ensureArchonWorkspacesPath is called Capture the @archon/paths mock as a named variable and assert it was called in the syncWorkspace handleMessage path. Without this, the test suite passes even if orchestrator-agent.ts:824 reverts to the non-ensuring getArchonWorkspacesPath() variant — exactly the regression that surfaced as 'Claude Code native binary not found' in coleam00#1528. * docs(changelog): add Tier 1 batch 2 cherry-pick entry Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> --------- Signed-off-by: kagura-agent <kagura.agent.ai@gmail.com> Co-authored-by: Rasmus Widing <152263317+Wirasm@users.noreply.github.com> Co-authored-by: DIY Smart Code <thomas@thirty3.de> Co-authored-by: Cocoon-Break <54054995+kuishou68@users.noreply.github.com> Co-authored-by: Kagura <kagura.agent.ai@gmail.com> Co-authored-by: Claude Opus 4 (1M context) <noreply@anthropic.com> Co-authored-by: Yasser <116118149+YrFnS@users.noreply.github.com> Co-authored-by: Truffle <truffleagent@gmail.com> Co-authored-by: cjnprospa <sirhcle.j23@gmail.com>
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
2 participants
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.
Summary
Failed to load conversations/projectswithECONNREFUSEDin the Vite log. Reported in bug(setup): fresh install on Windows 11 leaves web UI broken — .env not created, server (:3000) and Vite proxy (:3090) default to different ports #1152.PORT=3000from the wizard-generated.env, comment it out in.env.example, fix the stale JSDoc"default 3000"inport-allocation.ts, and update the wizard's "Additional Options" note.deploy/.env.examplekeepsPORT=3000(Docker compose/Caddy target it) but now carries a comment so someone copying it for local dev won't be silently misled.basePort(still 3090, the current code default), no change to Vite's fallback (already 3090, correct), no change to the Hono server's dual-.envloading (repo/.env+~/.archon/.envwithoverride: true). The underlying asymmetry (Hono reads both, Vite reads only repo-local) is discussed but intentionally left alone — narrowing the fix to the three drift points that are safe to align.UX Journey
Before
After
Architecture Diagram
Before
After
Connection inventory:
.env.env(repo + ~/.archon)apiPortgetPort()Label Snapshot
risk: lowsize: XScliconfigdocscli:setup,core:port-allocationChange Metadata
bugcliLinked Issue
basePortbecame 3090)Validation Evidence (required)
E2E verified on this branch (with
.envtemporarily removed, fresh-clone scenario):Pre-existing failing test in
packages/workflows/src/defaults/bundled-defaults.test.tsis unrelated — caused by an untracked.archon/workflows/defaults/archon-feedback.yamlin my local working tree, not by any change in this PR.Security Impact (required)
NoNoNoNoCompatibility / Migration
Yes— existing users withPORT=3000explicitly set in their.envkeep that behavior (explicit PORT always wins at server and Vite). Only unset/new installs switch to 3090.Yes—.env.exampledefault commented out. Existing.envfiles on disk are untouched.No~/.archon/.envfrom an earlierarchon setupcontinue to work; the explicitPORT=3000there still takes effect. To move onto the 3090 default they can delete thePORT=line.Human Verification (required)
.envanywhere: server binds 3090, Vite proxies 5173 → 3090,/api/healthreturns 200 through the proxy.@archon/clitests pass with the updatedgenerateEnvContentassertions.PORT=3000in.env— unchanged (explicit value wins at both server and Vite).deploy/.env.exampleto repo root — now sees the comment explaining it is a Docker default.bun run validatewas blocked by a pre-existing bundled-defaults drift unrelated to this change (an untracked file in my local tree); the individual validation steps all pass.deploy/.env.exampleis a text-only change).Side Effects / Blast Radius (required)
archon setupwizard output (.envgeneration) — no longer writes an explicit PORT line by default..env.exampleread by anyone copying it as a starting point — they no longer start on 3000 unless they uncomment.setup.test.tsasserts both positive (# PORT=3090present) and negative (no uncommentedPORT=line) conditions — catches any regression that reintroduces a hardcoded PORT.Rollback Plan (required)
git revert <merge-sha>— commit is small and self-contained.archon setup, check whether their~/.archon/.envstill hasPORT=3000written by a pre-revert wizard run.Risks and Mitigations
Risk: Users with an existing stale
~/.archon/.envcontainingPORT=3000(from a prior wizard run) continue to see server bind on 3000 while Vite proxies to 3090 — the original bug persists for them.PORT=line from their global.env.Risk: Downstream docs might still reference
:3000as "the" default.packages/docs-web/src/content/docs/already documents the 3090-local / 3000-Docker split correctly (via Fix failing react tests #318 follow-ups). No further doc changes needed in this PR.Summary by CodeRabbit
PORTconfiguration will automatically use the new default. If you previously relied on port 3000, you may need to adjust your environment configuration or explicitly setPORT=3000in your.envfile.