Tokitoki Windows

A native Windows tray app for Tokitoki. The app is a small Go executable that uses the shared github.com/tokitoki-dev/tokitoki-cli/pkg/agentlib package for local AI usage scanning and upload.

Architecture

tokitoki-windows.exe
  ├─ native Windows tray and settings UI
  ├─ launch-at-login registry integration
  ├─ recursive Claude Code / Codex directory watcher
  ├─ periodic sync scheduler
  └─ agentlib sync engine from the tokitoki-cli module

The Windows client does not bundle or spawn a separate agent process. It builds one executable and shares the same ~/.tokitoki state as the CLI.

All server access uses TOKITOKI_BASE_URL and defaults to https://tokitoki.dev. Override it before starting the app when testing a local or staging server:

$env:TOKITOKI_BASE_URL = "http://localhost:9093"
.\tokitoki-windows.exe

The agent library

agentlib comes from the published github.com/tokitoki-dev/tokitoki-cli module at the version go.mod pins. CI and the release workflow build exactly that: they check out this repo alone and resolve the pin from the module proxy, so a release always links published, tagged library code.

Local development instead builds from the sibling ../tokitoki-cli source checkout, through a gitignored go.work in this directory:

go 1.25.0

use (
	.
	../tokitoki-cli
)

With that file present, every go build / go test here links the sibling source, so app and CLI changes can be developed together without cutting a CLI release. Because go.work never gets committed, it cannot leak into CI. To reproduce the exact release build locally, disable the workspace:

GOWORK=off go build ./...

To move a release to a newer CLI, tag it in tokitoki-cli first, then bump the pin here:

GOWORK=off go get github.com/tokitoki-dev/tokitoki-cli@v0.1.4
GOWORK=off go mod tidy

Build

make build

The release executable is written to:

dist/tokitoki-windows-amd64.exe

For compatibility, the default amd64 build also writes:

dist/tokitoki-windows.exe

make without a target also runs make build.

Build Windows on ARM:

make build-arm64

That writes:

dist/tokitoki-windows-arm64.exe

Build both release architectures:

make build-all

Set release metadata:

make build-all VERSION=1.0.0 COMMIT=$(git rev-parse --short HEAD)

Development builds keep a console for diagnostics:

make debug

If the manifest resource needs to be regenerated:

make generate

Release

Releases are cut by tag. Pushing vX.Y.Z runs .github/workflows/release.yml, which tests, builds both architectures, checks each binary really is the architecture it claims, and publishes a GitHub release carrying:

tokitoki-windows-amd64.exe
tokitoki-windows-arm64.exe

Those names are what the server's asset matcher reads, so it can hand each machine the right build. The unsuffixed dist/tokitoki-windows.exe produced by local builds is deliberately not published.

The tag must point at a commit on main — the workflow refuses otherwise — so merge first, then:

git switch main
git merge --ff-only dev
git push origin main
git tag v0.1.0
git push origin v0.1.0

A published GitHub release does not ship anything to users on its own; rolling it out still happens in /admin/releases.

License

Licensed under the Apache License, Version 2.0.