NullClaw
NullClaw’s scheduler generated a pairing token but never persisted it
A NullClaw patch traces scheduler 401s to /pair storing a token hash only in memory while cron reads a paired_token file that never existed. The proposal encrypts the token at rest, keeps plaintext compatibility, and sits beside a new local Grok CLI provider that relies on a separate login session.
nullclaw/nullclaw PR #980 is the inspected primary source: “fix(scheduler): persist paired token to disk during /pair.” The two related records below were inspected as supporting context, not treated as independent confirmation.
The facts
- nullclaw/nullclaw PR #980 was created 2026-07-29T22:09:27Z and was open at inspection; its title is “fix(scheduler): persist paired token to disk during /pair.” - nullclaw/nullclaw issue #915 was created 2026-05-15T14:06:03Z and was open at inspection; its title is “Problem with scheduler unauthorized.” - nullclaw/nullclaw PR #981 was created 2026-07-29T22:47:30Z and was closed at inspection; its title is “feat(provider): add grok-cli provider for xAI Grok CLI.” - The repository reported 7964 stars, 82 open issues, default branch main, and last push 2026-07-19T04:20:06Z. - The latest tagged-release baseline checked was v2026.5.29 published 2026-05-29T13:41:10Z.
What changed
nullclaw/nullclaw PR #980 reports: Fixes #839 The /pair endpoint generates a token and stores its hash in memory, but never writes it to disk. The cron/schedule tool reads from {config_dir}/paired_token to authenticate against gateway admin routes, but since the file never exists, readPairedToken() returns null and the gateway returns 401. Changes src/gateway.zig (write path) After successful pairing in the.paired => |token| handler, persist the token to {config_dir}/paired_token encrypted at rest via SecretStore.encryptSecret() (ChaCha20-Poly1305) Failure to persist is logged as a warning but doesn't break the pairing response — the in-memory token still works
nullclaw/nullclaw issue #915 reports: Description i'm running nullclaw in ubuntu, with an ollama external host on the same network, with qwen3.6:27b on a RTX 3090. The LLM is working fine, and tool calling in nullclaw in general also works mostly fine. the problem i have is that scheduler is not working. not in telegram chat nor cli command. If I ask my bot in telegram to schedule a message in 15 minutes, it always answers me that it is receiving an unauthorized error. I also attached the config file (with telegram bot redacted). [config.json]
nullclaw/nullclaw PR #981 reports: Summary Add a new CLI-based provider that delegates to the local grok CLI (xAI Grok). Follows the same spawn-per-request pattern as codex-cli. Changes Core implementation **New src/providers/grok_cli.zig** — Full Provider.VTable implementation: Spawns grok -p --model --single --output-format plain for each request Concatenates system prompt with user message for chatWithSystem Extracts last user message for chat Validates CLI availability via grok --version during init() No vision or native tool support (CLI-only) Wiring **factory.zig**: Added grok_cli_provider to enum, core_providers map, ProviderHolder union, fromConfig() (with OpenRouter fallback), test helpers **provider_probe.zig**: Added to providerRequiresApiKey
Why it matters
Authentication must survive the same restart and execution boundary as the job that consumes it. A successful pairing response is false comfort if background work cannot read a durable credential afterward. This is an operator boundary: persisted state, execution ownership and visible controls must describe the same event. A workaround that broadens access, deletes state or hides the symptom would trade a visible defect for an unmeasured one.
Current
The primary record was open when captured on 2026-07-30. The release baseline was v2026.5.29 published 2026-05-29T13:41:10Z. Current repository metadata, pull requests, issues, release records, Google News discovery, Hacker News discovery, Lobsters, Metamesh and the rendered ClawCharts row were checked. ClawCharts selected the subject; it did not prove the claim.
Evidence
The primary URL is https://github.com/nullclaw/nullclaw/pull/980. Supporting records are https://github.com/nullclaw/nullclaw/issues/915 and https://github.com/nullclaw/nullclaw/pull/981. Their source bodies, timestamps and states were captured in the daily evidence bundle. Test counts, reproductions and deployment observations remain attributed to their authors unless explicitly identified as independently rerun.
Source boundary
Open work is described as open, closed work as closed, and operator reports as reports. A pull request is evidence of proposed or reviewed direction, not proof of a shipped release. Issue closure would not by itself prove a deployed fix. Search residue, package mirrors and historically published source spines were excluded.
Operator take
Verify pair, restart and scheduled execution as one flow; keep file permissions and decryption failures visible, and do not conflate CLI login state with gateway pairing authority. Preserve a before-state receipt, make the smallest reversible change, and verify the original failure independently after intervention.
Caveat
Public project records are mutable. Status, scope and evidence can change after publication. This brief records the inspected state and does not authorize changes to a reader’s deployment.
Source inspected; source state, environment and release boundary remain explicit.