From ec97861db6260a86256e17f799ec7588c8de5a0b Mon Sep 17 00:00:00 2001 From: Wolfgang Schoenberger <221313372+wolfiesch@users.noreply.github.com> Date: Mon, 26 Oct 2026 02:54:18 -0700 Subject: [PATCH] Make Windows host builds reproducible The release workflow builds the host twice and compares the results. For x86_64-pc-windows-msvc the two builds differed at byte 257, the PE header timestamp the MSVC linker writes at link time, so the v2.0.0-rc.1 release run failed before signing. Link Windows MSVC targets with /Brepro through a root .cargo/config.toml, which every workflow picks up because cargo runs from the repository root. Verified on Windows 11 with VS 2022 Build Tools using the release workflow's build, clean, rebuild, and cmp steps: main differs at byte 257; with this change, two separate runs both produce identical binaries with the same SHA-256. --- .cargo/config.toml | 6 ++++++ CHANGELOG.md | 1 + 2 files changed, 7 insertions(+) create mode 100644 .cargo/config.toml diff --git a/.cargo/config.toml b/.cargo/config.toml new file mode 100644 index 0000000..d89abb3 --- /dev/null +++ b/.cargo/config.toml @@ -0,0 +1,6 @@ +# The MSVC linker stamps the link time into every PE header, so two release +# builds of the same source differ and the release workflow's determinism check +# fails. /Brepro replaces the timestamp and debug-directory GUID with values +# derived from the binary's contents. +[target.'cfg(all(windows, target_env = "msvc"))'] +rustflags = ["-C", "link-arg=/Brepro"] diff --git a/CHANGELOG.md b/CHANGELOG.md index dab5b77..7d1cfbe 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -1,6 +1,7 @@ # Changelog ## Unreleased +- Windows host builds are now reproducible. The MSVC linker wrote the link time into each executable, so two builds of the same source differed and the release workflow's determinism check failed for `x86_64-pc-windows-msvc`. A root `.cargo/config.toml` now links Windows MSVC targets with `/Brepro`, which derives the timestamp and debug identifier from the binary's contents. - The host now closes a task after 24 hours with no connection, owned tab, or staged Commit. Previously a task stayed open until an agent finished or closed it explicitly, so every session that disconnected without finishing left an open task in `state.sqlite3` indefinitely. Tasks that own tabs are never closed this way, and a task that was connected when the host stopped counts its idle time from the restart. - A connection acknowledgement that does not resume a supplied capability now carries `resume_rejection`: `task_closed` when the task was finished or closed, or `unknown_capability` otherwise. The host keeps closed tasks' capability hashes for a year to tell the two apart. On `task_closed`, the TypeScript and Python SDKs, and through them the MCP, OMP, Pi, and GPT-Control adapters, clear the stored capability and connect as a new task instead of failing with "rejected the stored resume capability" until the state was deleted by hand. Any other rejection still refuses to connect and keeps the stored capability. - Added `clear()` to the Python SDK's resume capability store. `finish_task` already called it, so finishing a task with the built-in file store raised `AttributeError`.