Publish wiki from 5089df0
Source of truth is wiki/ in the code repo. Do not edit here - browser
edits are overwritten on the next publish.
Publish wiki from 39465a6
Source of truth is wiki/ in the code repo. Do not edit here - browser
edits are overwritten on the next publish.
Publish wiki from 6c023d4
Source of truth is wiki/ in the code repo. Do not edit here - browser
edits are overwritten on the next publish.
Publish wiki from 05246db
Source of truth is wiki/ in the code repo. Do not edit here - browser
edits are overwritten on the next publish.
Ground the Windows node.exe recommendation in schtasks documentation
The previous wording argued from absence: Microsoft does not define how far
a task stop reaches, so avoid having a process tree. There is a better
citation. schtasks /end documents that stopping a task "Stops only the
instances of a program started by a scheduled task. To stop other
processes, you must use the TaskKill command."
That states the boundary positively. A stop covers the task's program;
anything that program launched is one of the "other processes". So if the
task's program is powershell.exe, the relay is a child and is not covered.
Making node.exe the task's program puts the relay exactly inside what a
stop covers. Same recommendation, argued from what the docs say rather
than from what they omit.
Also corrects a detail. The .ps1 shim is a script, not a separate process
- it runs in the calling host and launches node from there. The extra
layer came from the previous page setting -Execute "powershell.exe", not
from the shim. Worth being exact, since that action is what this page
replaces.
Refs D0n9X1n/copilot-relay#29
Soften an unsupported claim about Windows process-tree termination
The Windows pages stated that "process-tree termination is not reliable
once the intermediate shell has exited". That is a mechanism claim, and
Microsoft's documentation does not support it - the docs say a task is
"stopped" and separately that AllowHardTerminate permits termination via
TerminateProcess, but never define how far down a process tree a stop
reaches.
The recommendation is unchanged, because it does not depend on that claim:
executing node.exe directly means there is no tree to walk, so start and
stop map 1:1 to the relay regardless of the behavior. Restating it that
way removes the assertion without weakening the advice.
The troubleshooting entry is left as-is; it describes a symptom the reader
observes rather than asserting why it happens.
Refs D0n9X1n/copilot-relay#29
Rewrite service pages: fix 30 stale log paths, throttle restarts, add real health checks
Three defects across the six service pages (EN + ZH x macOS/Windows/Linux).
Stale log paths. v0.2.3 changed the active log to a dated filename, so 30
references across 10 pages pointed at a file nothing writes to any more -
every documented tail and grep silently matched nothing. The two
Logging-Troubleshooting pages carried 11 each.
Crash loops at boot. startRelay exits 1 when upstream preflight fails, and
at boot the network is frequently not up yet, so every platform restarted
it immediately and forever. macOS had KeepAlive: true with no throttle,
Linux Restart=always with RestartSec=5, Windows RestartCount 999. All
three now throttle, and macOS/Linux use SuccessfulExit: false /
Restart=on-failure so a clean `copilot-relay stop` is not fought by the
supervisor.
Verification proved nothing. Every page verified with curl /healthz, which
is a static handler. /v1/models is no better - it maps config and never
contacts upstream. A relay whose Copilot token expired an hour ago passes
both. Pages now document three layers and state what each does and does
not prove; only POST /v1/messages exercises token refresh and a real
Copilot call. Verified against a live relay: 200, reply 'ok', usage
in=13 out=5.
Windows page additionally corrects settings whose defaults are wrong for a
long-lived service, verified against Microsoft Learn:
- ExecutionTimeLimit defaults to PT72H and Task Scheduler *terminates* the
task at that point. A healthy relay dies after 3 days and it looks like
a normal completion. Fingerprint is LastTaskResult 267014.
PowerShell's [TimeSpan]::Zero does not reliably serialize to PT0S, so
the page now includes a post-registration check and an XML fallback
rather than asserting it works.
- StopIfGoingOnBatteries and DisallowStartIfOnBatteries both default true,
so both switches are required on a laptop.
- -DisallowStartIfOnBatteries is not a cmdlet parameter; the old page
passed it.
- RestartCount applies only on failure, so exit 0 is never undone by it.
- Execute node.exe directly: npm's Windows shims put a shell between Task
Scheduler and the relay, and process-tree termination is unreliable once
that shell exits.
Refs D0n9X1n/copilot-relay#29
Split wiki by platform and language
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>