You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
port(go): Windows localized scheduler elevation recovery from #698 #703
The Go runtime does not use the TypeScript CLI subprocess/elevation bridge:
go/internal/cli/runtime_management.go handles POST /api/startup-action by calling runService([]string{"install"}, ...) in-process.
go/internal/service/install.go calls schtasks.exe /create /tn opencodex-proxy /xml ... /f and returns raw CombinedOutput on failure.
There is no structured scheduler-create access-denied error, effective-token probe, fixed UAC transaction, or rollback protocol in the Go path.
Cherry-picking the TypeScript files from #698 therefore does not fix the primary Go runtime.
Required port invariants
Preserve recognized localized access-denied handling, but do not depend on localized text for unreadable/OEM-code-page output.
The locale-independent fallback must require the exact owned create shape (/create, task opencodex-proxy, XML path, /f), exit status 1, and a confirmed non-elevated effective token.
An unavailable token probe fails closed and retains the original error for the unreadable-text fallback.
Foreign tasks and query/run/delete/native-service/file-write failures must never cross the elevation boundary.
Any Go UAC transaction must resolve trusted Windows system executables, accept only the fixed scheduler command, bound execution/output, distinguish cancellation, and roll back a created task if start/verification fails.
Direct CLI should receive actionable language-independent guidance; the dashboard action may request UAC only through the fixed trusted transaction.
Add Windows-focused unit tests for non-English/mangled output, elevated/non-elevated/unknown token states, foreign task denial, and transaction rollback/failure outcomes.
Update the Go architecture/service SOT if the selected transaction differs from the TypeScript bridge.
Closing: the dev2-go Go native-port line is retired, so this port obligation no longer exists.
The dual-track policy required every merge into dev to be rebased onto dev2-go and ported under go/. That cost outran its return — the carry backlog never cleared and dogfooding the Go runtime kept producing new defects. Bun-native TypeScript on dev is the single runtime line again.
The TypeScript change this issue tracked is already on dev; only the Go counterpart is dropped. Future native work is expected to be an incremental module on dev (Rust via N-API is the current candidate) rather than a second integration branch. See MAINTAINERS.md for the decision record.
Closing this as not planned: the Go native-port line it belonged to has been retired.
What changed. We ran dev (Bun-native TypeScript) and dev2-go (Go native port) as two integration lines, and every merge into dev carried an obligation to port the same change onto dev2-go. In practice that dual track cost more than the port returned — dogfooding the Go runtime kept surfacing new defects faster than we closed them, and the carry queue never emptied. So dev is once again the single integration line, and there is no port obligation attached to a dev merge any more.
Nothing is lost. The full dev2-go history is archived at lidge-jun/opencodex-go-archive, and the final tip is tagged archive/dev2-go in this repository. If native code returns, the plan is an incremental module (for example Rust via N-API) landing on dev, not a second full-runtime branch.
The underlying fix is already on dev — this issue only tracked the missing Go counterpart, so there is no behavior regression from closing it. The needs-go-port label is retired as well.
Sorry for the churn, and thank you for the carry and port work you put into this line. It was genuinely useful for learning where the runtime boundaries are; the direction change is on me, not on the work.
Activity
github-actions commentedon Jul 29, 2026
Automated translation bookkeeping — detected language: English.
lidge-jun commentedon Jul 29, 2026
Closing: the
dev2-goGo native-port line is retired, so this port obligation no longer exists.The dual-track policy required every merge into
devto be rebased ontodev2-goand ported undergo/. That cost outran its return — the carry backlog never cleared and dogfooding the Go runtime kept producing new defects. Bun-native TypeScript ondevis the single runtime line again.The branch history is preserved read-only at https://github.com/lidge-jun/opencodex-go-archive, and its final tip stays reachable in this repository as the
archive/dev2-gotag. Theneeds-go-portlabel is retired.The TypeScript change this issue tracked is already on
dev; only the Go counterpart is dropped. Future native work is expected to be an incremental module ondev(Rust via N-API is the current candidate) rather than a second integration branch. SeeMAINTAINERS.mdfor the decision record.lidge-jun commentedon Jul 29, 2026
Closing this as not planned: the Go native-port line it belonged to has been retired.
What changed. We ran
dev(Bun-native TypeScript) anddev2-go(Go native port) as two integration lines, and every merge intodevcarried an obligation to port the same change ontodev2-go. In practice that dual track cost more than the port returned — dogfooding the Go runtime kept surfacing new defects faster than we closed them, and the carry queue never emptied. Sodevis once again the single integration line, and there is no port obligation attached to adevmerge any more.Nothing is lost. The full
dev2-gohistory is archived at lidge-jun/opencodex-go-archive, and the final tip is taggedarchive/dev2-goin this repository. If native code returns, the plan is an incremental module (for example Rust via N-API) landing ondev, not a second full-runtime branch.The underlying fix is already on
dev— this issue only tracked the missing Go counterpart, so there is no behavior regression from closing it. Theneeds-go-portlabel is retired as well.Sorry for the churn, and thank you for the carry and port work you put into this line. It was genuinely useful for learning where the runtime boundaries are; the direction change is on me, not on the work.