Chalie can now push code, and v0.8.0 ships

Today had two jobs: land a capability I’d been wanting for a while, and get v0.8.0 out clean. Both happened, neither at the other’s expense.

The headline is Git. Chalie can now read and write to GitHub and GitLab repos as a toggleable capability — no token, and it can read any public repo; add a personal access token, and it can clone, commit, push to a feature branch, and open or merge a pull request. The architecture is hybrid on purpose: file operations (clone, diff, commit, push) go through the real git CLI as argument lists, never a shell, so there’s no injection surface, while PRs, issues, releases, and search go through the GitHub v3 and GitLab v4 REST APIs directly. Self-hosted instances work too, behind a configurable host field with SSRF protection — “self-hosted git” becomes a liability fast if you don’t think about where a hostname can point. The token never touches argv, a URL, or a config file — it’s injected via a locked-down helper script deleted the instant the operation finishes, and redacted from every output line before Chalie sees it. Reads are allowed everywhere by default; writes ask for confirmation in chat and subagent contexts, and are denied outright in fully autonomous ones — no unattended process pushes code without a human in the loop.

Shipping a capability that handles credentials meant the day ended only when the security scan was clean, not when the feature worked. The git client had a TLS fallback that silently downgraded to an unverified connection on a certificate error — the wrong failure mode for a client carrying an access token; that fallback is gone, certificate validation now unconditional. A second pass caught the askpass helper being written inside the directory it was about to clone into — meaning git clone would occasionally refuse to run because the destination wasn’t empty, and worse, the script could be swept into a commit. It now writes to its own private temp file. And in the same spirit as recent work on never truncating what the model sees, every artificial cap on Git output — diff size, file listings, PR bodies, error text — is gone, replaced by one 30-minute timeout that fires only on a genuinely hung process.

The rest of the day closed out v0.8.0: the version file was bumped to match the build config, and a pre-release lint pass caught and fixed two small regressions before they could ride into the release. I also closed a quieter loose end: a service deleted weeks ago still had an entry in the list of files allowed to call the full ability registry. Harmless while the file stayed gone, but a new file with that exact name would have been silently pre-authorized for a broad permission it shouldn’t get — better found in review than an incident report. Three UI and test fixes rounded things out: a theme toggle that accidentally navigated away from the dashboard, contrast bugs in a dialog and scrollbar under light theme, and two test suites drifted out of sync with reality.

None of this is one big feature — it’s a capability landing safely and a release going out clean, the kind of day that keeps the ones after it fast. Git access changes what Chalie can be asked to do: review a PR, fix something and push a branch, open the fix for a human to merge — a different category of assistant than one that can only talk about code. Next up: watching how that capability behaves once real repos and real tokens are in front of it.

• New Git capability: read/write access to GitHub and GitLab, hybrid git-CLI + REST architecture, SSRF-guarded self-hosted host support

• Access tokens never touch argv, URLs, or config — injected via a short-lived helper script and redacted from all output

• Closed a silent TLS-downgrade fallback in the Git REST client; certificate validation is now unconditional

• Removed every artificial output cap on Git operations in favor of one 30-minute hang-only timeout

• v0.8.0 shipped: version bump, pre-release lint fixes, a closed governance-bypass loose end, and light-theme/test fixes