Repository navigation
Conversation
Adds a WPF launcher (Launch Codexify.cmd) that starts the installed service, saved tunnels and the browser companion with live status, a console start script, autowork status helpers, and guarded local update tooling that never interrupts running agent work. Every script has a Windows PowerShell test. Also makes the installer test run under Windows PowerShell 5.1. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
devnoname120
left a comment
devnoname120
left a comment
There was a problem hiding this comment.
Reviewed 818a084, including the launcher/service entry points, process ownership checks, update/rollback paths and their split dependencies. Requesting changes for the inline findings.
The launcher is useful, but the bundled maintenance scripts are not ready to merge with it: two update paths accept a pool with an active action as idle, the console start path ignores the configured port, and the staged-agent helpers depend on a private, dated receipt directory with no initialization path in this branch.
Validation: parsed the added PowerShell scripts with PowerShell 7.7 (zero syntax errors); evaluated the actual Browser-Idle function definitions with a two-page health fixture containing one accepted action. Both windows-install-local-update.ps1 and windows-install-browser-patch.ps1 returned true, while Test-AgentUpdateBrowserIdle correctly returned false. This was an isolated function probe, not a Windows deployment or WPF UI run. The Windows/macOS service CI jobs passed. The check job's needless_bool diagnostic is in unchanged agent_automation/store.rs, so I am not attributing that failure to this PR.
Recommendation: keep this open until the update guards and standalone behavior are corrected and covered. The launcher portion is much closer to mergeable than the deployment helpers.
| $liveness=Invoke-RestMethod ($descriptor.endpoint.TrimEnd('/')+'/v1/liveness') -TimeoutSec 5 -Headers @{Authorization=('Bearer '+$descriptor.token)} | ||
| return [bool]$liveness.available | ||
| } | ||
| return $health.status -in @('idle','authentication_required') -and -not $health.activeActionId |
There was a problem hiding this comment.
[P1] Use the pool-aware idle guard before stopping the browser
With #22/#24's pool, an idle free page produces status="idle", activeActionId=null and activeActionIds=["accepted-action"] while another page still owns a Send. This predicate returns true for that real health shape, and the deployment path proceeds to browser stop, interrupting the active action. I reproduced this by evaluating this function with that health fixture; windows-install-local-update.ps1 has the same problem, and windows-browser-graceful-update.ps1 also checks only the singular field. The shared Test-AgentUpdateBrowserIdle helper already rejects this shape, but these paths do not use it. Apply the complete ownership/capacity check consistently before any shutdown, including the final recheck, and add coverage at the updater entry points.
| $client=[Net.Http.HttpClient]::new($handler) | ||
| $client.Timeout=[TimeSpan]::FromSeconds(2) | ||
| function Read-LocalHealth { | ||
| try {return ($client.GetStringAsync('http://127.0.0.1:3000/health').GetAwaiter().GetResult() | ConvertFrom-Json)}catch{return $null} |
There was a problem hiding this comment.
[P2] Read the saved server port for console startup
START CODEXIFY.cmd launches this script against the saved codexify.config.json, but readiness is always polled on port 3000. A valid installation configured with another port starts correctly and then spends 60 seconds polling the wrong endpoint before reporting failure; an unrelated listener on 3000 can also satisfy the wrong readiness check. Read the configured port (using 3000 only as its default), and use it throughout this startup path. The WPF launcher already does this through Get-LauncherSettings.
| param([ValidateRange(1,8)][int]$Jobs=4) | ||
| $ErrorActionPreference='Stop' | ||
| $repo=Split-Path -Parent $PSScriptRoot | ||
| $ready=Join-Path $repo 'browser-companion/artifacts/ready-20261030' |
There was a problem hiding this comment.
[P2] Remove the dependency on a pre-existing private staging receipt
This path is neither created here nor present in the PR. Start-Process redirects output into it, Save-BuildState writes into it, and the later build path unconditionally reads agent-update.json from it. A clean checkout therefore cannot run the advertised build helper, even with all build tools and an installed service available; the activation helper also requires the same unprovided receipt. Parameterize/create the staging area and provide a documented way to generate its initial receipt, or keep these one-off deployment helpers out of the standalone launcher PR.
Opens process handles early so exit codes are not null, snapshots chat state with robocopy to survive long paths, tolerates Chrome's background process after a clean window close, skips the graceful close when the browser is already stopped, and starts the existing elevated scheduled task when its launcher cannot be upgraded without admin rights. Adds -ConfigSet to apply validated settings before the single restart and -AllowActiveCommands to update without waiting for every agent command to finish. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- Share Test-BrowserPoolUnowned between the agent-update guards, both installers and the graceful browser shutdown, including its final recheck. A free page can report idle while another page owns a Send. - START CODEXIFY polls the configured server port instead of 3000. - Add entry-point coverage for the installers' idle predicates and the console port. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- Remove windows-build-agent-update.ps1 and windows-activate-agent-update.ps1. They were one-off deployment helpers tied to a dated, uncommitted staging receipt and cannot run from a clean checkout. - The renderer priority helper writes its status to ~/.codexify/logs. - Updater tests use the system temp directory instead of D:/CodexifyBuild, and the graceful-shutdown fixture runs its stop helper with the current PowerShell host, so it also runs under Windows PowerShell 5.1. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
Thanks for the review. All three findings are addressed: [P1] Pool-aware idle guard (86ce3af)
[P2] Console port
[P2] Private staging receipt (bc5502e)
This also picks up d2bf7a6, a set of Windows PowerShell 5.1 fixes from a real deployment of this updater:
Validation on Windows 11 / PowerShell 5.1: |
Summary
Split out of #20, as requested. This PR has only the Windows launcher and local service tooling. Every file is a new script, plus one installer-test fix, so it can be reviewed and merged on its own. Based on current
main(v2.3.29).Changes
Native launcher
Launch Codexify.cmdopens a WPF launcher (scripts/windows-launcher.ps1,windows-launcher-core.ps1,windows-launcher.xaml). The launcher starts the installed service, its saved OpenAI tunnel(s) and the browser companion, then shows live status.scripts/install-windows-launcher.ps1copies the launcher into%USERPROFILE%\.codexify\launcherand adds desktop and Start menu shortcuts. No admin rights are needed. It runs on Windows PowerShell 5.1 and WPF.docs/WINDOWS_LAUNCHER.md. The README links it from the install section.Console start
START CODEXIFY.cmdandwindows-start-local(-core).ps1start the installed service in a console. They don't create or change scheduled tasks.Autowork status
windows-autowork-status.ps1,windows-autowork-state-files.ps1andwindows-autowork-team-status.mjsgive a read-only snapshot of the service. It covers server and browser readiness, supervisor count, free disk, active goals, last tool activity and retry errors.Guarded local updates
windows-build-agent-update.ps1,windows-activate-agent-update.ps1,windows-install-local-update.ps1andwindows-install-browser-patch.ps1build and install a local update without interrupting running agent work.windows-agent-update-guards.ps1checks for that work before anything is replaced.windows-browser-graceful-update.ps1andwindows-stage-browser-patch-on-exit.ps1defer a browser update until Chrome exits cleanly. They never terminate a live Chrome profile.windows-browser-only-native-backup.ps1,windows-live-renderer-priority.ps1,windows-apply-navigation-stall-patch.ps1,windows-update-file-server.cjs.Installer test
scripts/test-windows-installer.ps1now runs under Windows PowerShell 5.1.$IsWindowsis undefined there under StrictMode, and 5.1 wraps captured output at the host width.Testing
scripts/test-windows-launcher.ps1andscripts/test-windows-start-local.ps1pass on Windows 11 with Windows PowerShell 5.1.scripts/test-windows-autowork-state-files.ps1passes.test-windows-agent-update-guards.ps1,test-windows-browser-graceful-update.ps1,test-windows-stage-browser-patch-on-exit.ps1) need PowerShell 7 (#Requires -Version 7.0). They were not run for this PR.🤖 Generated with Claude Code