UrbanWafflezz/GilbertCodex

Gilbert Codex v0.3.5 is a major public alpha update focused on rebuilding the tool runtime into a professional provider tool bridge, refreshing the contributor-facing documentation, and preparing the project for a cleaner open-source release cycle.

The release moves the product past the reset-era tool story. Gilbert now has a typed bridge for advertising tools to providers, validating calls, executing safe batches, requesting approval for risky actions, recording visible activity, and sending bounded tool results back to the model for final synthesis.

This is still alpha software. The bridge is far more capable than the v0.3.0 reset path, but provider/model differences still matter and some tool-call edge cases are expected while the app gathers real-world compatibility reports.

Release Status

• Version: 0.3.5
• Tag: v0.3.5
• Previous public milestone: v0.3.0
• Primary packaged target: Windows x64
• Release vehicle: GitHub Actions Release workflow plus Tauri NSIS installer
• Installer family: Gilbert-Codex-0.3.5-x64-setup.exe
• Update feed asset: latest.json
• Updater signature asset: Gilbert-Codex-0.3.5-x64-setup.exe.sig
• Checksum asset: Gilbert-Codex-0.3.5-x64-setup.exe.sha256
• Published SHA-256: pending final release build

Do not fill the checksum until the final installer artifact has been built and uploaded. Keep the GitHub Release body aligned with this file.

Who This Build Is For

This build is for people who want to test Gilbert Codex as a local-first desktop coding agent workspace:

• Developers who want chat, tool activity, local files, terminal sessions, browser preview, web sources, and source-control context in one app.
• Alpha testers who can report provider/model tool-call reliability with concrete prompts and model IDs.
• Contributors who want a clearer source tree and a more testable runtime boundary.
• Maintainers preparing release notes, installer artifacts, and public issue triage for a wider audience.

Major Tool Bridge Rebuild

v0.3.5 introduces the provider tool bridge under src/toolBridge/.

The bridge owns:

• Provider adapters for OpenAI-compatible chat, OpenAI Responses, and Anthropic Messages.
• Tool schema registration and provider compatibility filtering.
• Permission filtering by local workspace mode and tool risk.
• Parallel batch execution for safe tool calls.
• Approval callbacks for terminal, destructive, credential, publish, and outside-scope work.
• Validation before execution so malformed calls fail clearly.
• Visible ChatToolCall records for activity cards and inspector surfaces.
• Tool result finalization so raw tool output does not become the final answer by accident.
• Provider-context budgeting so completed tool output can help follow-up turns without flooding the request body.

Tool families now include diagnostic tools, file reads/search/listing, editing, terminal execution, browser preview, local Git, GitHub API-backed actions, web search, and MCP-facing discovery/call surfaces where provider support, settings, and permissions allow them.

Provider Request Integration

The model-provider clients now attach bridge tools and prior tool results directly to provider request bodies instead of relying on visible XML-style protocol text.

Important behavior:

• OpenAI-compatible providers receive tool schemas and tool result messages in their native chat shape.
• OpenAI Responses requests receive bridge state through the Responses-compatible adapter.
• Anthropic Messages requests receive tool definitions and result content in Anthropic's expected shape.
• The request accounting path includes tool schemas and bounded tool output so the context meter better reflects what providers actually see.
• Synthesis turns can disable additional tool calls after a tool batch completes, which helps force a final user-facing answer.

Tool Activity And Final Answer Flow

The visible activity layer now has a stronger contract:

• Tool calls are app-owned records, not raw assistant prose.
• Active, waiting, skipped, failed, and completed states are visible.
• File-change summaries and terminal/browser details can be surfaced without exposing hidden provider protocol text.
• Completed tool output can require a synthesis pass when the model needs to explain results instead of dumping raw output.
• Duplicate tool-call IDs are detected and skipped so the app does not double-execute the same provider call.

Workspace, Files, And Editing

The file and editing surfaces are being rebuilt around typed operations:

• File listing, reading, range reading, search, stat, tree summary, and line counting are available through the bridge.
• Editing actions use explicit write, exact-replace, range-replace, insert, move, append, and patch tools.
• Paths are resolved against configured workspace roots before touching disk.
• Browser workspace fallback paths remain separate from desktop filesystem paths.
• Expected checksums and line-ending controls are available for safer writes where supported.

Terminal, Browser Preview, Git, And GitHub

v0.3.5 continues the work needed for real coding sessions:

• Terminal commands run through the native terminal manager with workspace cwd, timeout handling, captured output, and background-session support for dev servers.
• Host environment variables are scrubbed before child process launch so user projects do not inherit Gilbert's own dev-server configuration.
• Browser preview can open local or public URLs and expose inspection results through the app surface.
• Local Git tools cover status, diff, init, branch, stage, commit, pull, push, and worktree-style flows.
• GitHub tools use the connected OAuth account for repository reads, branch/file operations, commits, PRs, releases, workflow dispatch, and workflow run inspection.

High-impact terminal, GitHub publish, credential, destructive, and outside-scope actions should remain review-gated.

Web Search And Research Context

Web search remains host-managed and source-focused:

• DuckDuckGo/Brave search uses a six-source cap per web call.
• Source cards are attached to chat for citations and inspector review.
• Planning and thinking mode can receive live web context without losing citation requirements.
• Browser fallback behavior stays separate from desktop Rust search routing.

Documentation And Open-Source Prep

This release prep updates:

• README.md
• PROGRESS.md
• docs/ROADMAP.md
• docs/releases/v0.3.5.md
• docs/discord/README.md
• docs/github/README.md
• docs/platform/README.md
• docs/promo/README.md
• docs/AGENT_PROMPT_ARCHITECTURE.md
• contributor comment standards and prompt/runtime wording where needed

The README now includes a dedicated SVG wordmark for a more polished GitHub landing page.

Upgrade Notes For Users

• Install the Windows x64 setup executable from GitHub Releases.
• If Windows SmartScreen appears, review the source before continuing. This alpha is unsigned unless a signed build is provided.
• Configure provider keys, local endpoints, GitHub OAuth, Discord, and workspace permissions from Settings.
• For local models, start LM Studio or Ollama first, confirm the endpoint is reachable, then select the matching provider/model in Gilbert.
• If a model answers normally but tools fail, try a different model and file an issue with the provider, model ID, prompt, and visible tool activity details.
• Keep local databases, logs, screenshots, provider errors, and workspace paths out of public issues unless they are sanitized.

Upgrade Notes For Maintainers

• Keep version fields aligned across package.json, package-lock.json, src-tauri/Cargo.toml, src-tauri/Cargo.lock, and src-tauri/tauri.conf.json.
• Keep docs/releases/v0.3.5.md aligned with the GitHub Release body.
• Use npm.cmd on Windows PowerShell if the npm shim is blocked by script policy.
• Run the focused JavaScript tool-bridge tests before release.
• Run the full build and Rust check before pushing a release tag.
• Confirm the release workflow has TAURI_SIGNING_PRIVATE_KEY and TAURI_SIGNING_PRIVATE_KEY_PASSWORD when updater artifacts are required.
• Confirm generated artifacts, logs, local database files, secrets, and dependency folders stay out of Git.

Validation Commands

Recommended local checks:

npm.cmd run test:tool-bridge
npm.cmd run build
npm.cmd run rust:fmt:check
npm.cmd run rust:check
npm.cmd run audit:prod
git diff --check

Recommended release build:

npm.cmd run app:release

The GitHub release workflow performs the Windows updater release build when the tag is pushed or the workflow is dispatched with a version input.

Known Issues

Provider And Model Tool Compatibility

Some models are better at provider tool calls than others. Expected alpha failure modes include ignored tool calls, malformed arguments, partial tool calls, wrong tool names, provider-specific schema constraints, or empty synthesis responses after tools run.

Workarounds:

• Try a model known to follow structured tool calls well.
• Try a local model through LM Studio or Ollama when cloud routing is unstable.
• Retry with a more direct instruction if the model drifted.
• Include provider, model ID, prompt, and visible tool activity details when reporting.

Approval UX Still Needs Polish

The bridge has risk-based gating, but approval cards, grouped activity, and final review surfaces still need more real-world refinement.

Windows-Only Packaged Release

Windows x64 is the only official packaged target for v0.3.5. macOS and Linux source support exists, but official release artifacts require native validation.

Unsigned Windows Installer

The installer is not Authenticode code-signed unless a release is built with valid signing configuration. SmartScreen warnings are expected on some machines.

Security And Privacy Notes

Gilbert Codex is local-first. Provider keys, GitHub tokens, Discord settings, local accounts, local databases, logs, workspace files, scan artifacts, release signing credentials, and updater private keys are local user data. They should not be committed or attached to public issues.

The release continues the repository hygiene posture:

• .env stays ignored.
• Local SQLite databases stay ignored.
• SQLite journal and WAL files stay ignored.
• Local scan outputs stay ignored.
• Dependency folders stay ignored.
• Build outputs stay ignored.
• Release signing credentials stay out of source control.

Production Readiness Posture

v0.3.5 is prepared for broader public alpha testing. It has a cleaner runtime boundary, more honest docs, stronger release prep, and a tool system that can be tested and improved by contributors.

It is not claiming perfect provider/tool reliability. The right release posture is to ship the build with explicit known issues, gather compatibility reports, and continue tightening the bridge with real evidence.