v1.6.0
Stable Β· 2026-06-22 Β· Previous stable v1.5.0
Three big things this release
Let me say it straight.
v1.5.0 made the employee verifiable β goals grew a checklist, the Wiki started maintaining itself, memory learned whose memory it is. This release is less about a single new superpower and more about where the employee can run, what it can do with its hands and eyes, and how directly you can shape who it is.
Three things: it now runs on the databases you may be required to use, it grew new senses and hands, and you can now shape its identity and reach without touching prompts.
First, it runs on domestic databases. KingbaseES (人倧ιδ») and PostgreSQL are first-class now. PostgreSQL and KingbaseES share one migration tree β the same SQL drives both, because KingbaseES speaks PostgreSQL. The PostgreSQL driver ships in the default build; the KingbaseES driver is opt-in (it isn't on Maven Central). MySQL and the desktop H2 default are untouched β this is a new option, not a forced migration.
Second, it grew new senses and hands. The employee can re-examine an image on demand and keep that image in context across turns β ask a follow-up about a screenshot you sent three messages ago and it still sees it, instead of having forgotten it after the first reply. And it can write and run code β execute_code lets the employee author a snippet and execute it, so "compute this," "transform that file," "verify this number" become real actions instead of guesses.
Third, you shape who the employee is β directly. Its context files (AGENTS.md and friends) now have a real editor: a modal, surfaced as a settings row, with section reordering. A static About You identity block goes into the system prompt. The employee even knows which model it's running on now, injected each turn. You can scope an employee's knowledge-base access to a bound subset, and filter the roster by tags.
Plus the medium things: the Wiki's raw materials and source watcher merged into one Sources tab with per-KB auto-sync and glob patterns; a global outbound proxy with a settings page; and final answers got deterministic, cleaner Markdown.
That's it.
1. It runs on domestic databases β KingbaseES + PostgreSQL
Until now production meant MySQL (with H2 for the desktop app). For teams in regulated or domestic-procurement environments, that was a wall. This release puts the employee on KingbaseES (人倧ιδ») and PostgreSQL.
One migration tree for the whole PostgreSQL family. KingbaseES is PostgreSQL-compatible at the SQL and wire level, so both run off the same migration tree (db/migration/kingbase) and the same seed data. There is no third hand-maintained copy of every migration β the PostgreSQL family is one set of scripts, written in portable PostgreSQL.
The drivers are handled differently, on purpose:
| Database | Driver | Build |
|---|---|---|
| PostgreSQL | org.postgresql (on Maven Central) |
in the default build β nothing extra |
| KingbaseES | com.kingbase8 (not on Maven Central) |
opt-in -Pkingbase Maven profile |
The KingbaseES driver isn't published to Maven Central, so making it a hard dependency would break mvn package for everyone who doesn't have the proprietary jar. Instead it lives in an opt-in profile β the default build never needs it, and KingbaseES users install the jar locally and build with -Pkingbase. No Java code imports the driver; both databases are selected at runtime by Spring profile (postgres / kingbase) and JDBC URL.
Strict-PostgreSQL portability. KingbaseES tolerates loose typing; stock PostgreSQL does not. The shared tree was hardened so it runs on both: boolean columns use real TRUE/FALSE instead of 0/1, a Kingbase-only SYS_GUID() became a portable md5(random()::text), and the seed data dropped Oracle-isms like FROM DUAL. Validated by applying all migrations plus both locale seeds against a real PostgreSQL instance.
Least-privilege roles in Docker. The production compose splits the database account in two: a bootstrap/superuser used only to initialize, and a restricted application role (owns its schema, runs migrations, but is not a cluster superuser) that the server actually connects with. An init script creates the app role safely (quoted identifiers and literals, so an exotic password can't break it).
MySQL and the H2 desktop default are unchanged. See Configuration for the profiles.
2. New senses and hands β vision in context, and code execution
It keeps the image, and can look again
Before, an image was analyzed once, at the moment you sent it, and the text result was all that survived. Ask a follow-up and the employee was reasoning over a caption, not the picture.
Now the image stays in context across turns. Send a screenshot, get an answer, then ask "what's the number in the top-right?" three messages later β the employee still has the image and answers from it. A new image_analyze tool lets it re-examine an image on demand β re-read the same image with a fresh, specific question instead of re-uploading.
This pairs with channel fixes so inbound images from IM (e.g. WeCom) are staged correctly rather than stored URL-only.
It can write and run code
The new execute_code tool lets the employee author a snippet and run it. "Compute the compound interest," "reshape this CSV," "check whether these two hashes match" β instead of an LLM estimating the answer in prose, the employee writes the code, runs it, and reports what actually came back. Verifiable arithmetic, real file transforms, real checks.
3. You shape who the employee is β and what it can reach
Context files got an editor
AGENTS.md and the other context files (SOUL.md / PROFILE.md / β¦) are how you tell an employee who it is and how to behave. This release gives them a real editor: open it in a modal, reach it as a row in the agent's settings, and reorder sections. The agent editor also lets you manage AGENTS.md directly and clarifies what each context file is for, so you're not guessing which file shapes what.
A static "About You" identity block
An explicit About You block is appended to the system prompt β a stable identity statement the employee always carries, separate from the dynamic per-turn context.
The employee knows which model it's running on
Each turn now injects a runtime model identity line β the employee is aware of the actual model and provider it's executing on. "Which model are you?" gets an honest answer, and behavior that should depend on the running model can.
Knowledge-base access can be scoped
An employee's wiki access can be scoped to a bound subset of knowledge bases (migration V141), instead of every KB in the workspace. The roster also gained tag filtering, and tags are edited with a chip-style editor.
4. The Wiki got a Sources tab
The Wiki's two ways of getting material in β uploaded raw materials and the local-directory source watcher β were separate surfaces. They're now one Sources tab per knowledge base, with per-KB auto-sync.
- Multi-path and glob source directories β a KB's source can be several paths and glob patterns, matched against the symlink-resolved scan root (no escaping the allowed roots).
- A guided form editor for the pageType profile β define a KB's page types through a form instead of hand-writing JSON (the JSON stays available for review).
- KB management and reading are now separate workspace views β browsing a knowledge base and administering it no longer share one cramped screen.
- Reclassify existing pages against the current pageType profile, and pageType profiles are now honored consistently across transformations, agent-authored pages, and the UI.
See LLM Wiki.
5. A global outbound proxy
A new proxy settings page configures a global outbound proxy for the whole server.
- HTTP(S) proxying covers all outbound traffic, including LLM API calls β useful when the box only reaches the internet through a corporate proxy.
- SOCKS is honored on the JDK HTTP paths (non-LLM traffic such as webhooks and file fetches); some HTTP clients ignore SOCKS, so LLM calls should use the HTTP(S) form.
Settings are applied live and shown back in the UI with the active proxy host/port and type.
6. Cleaner answers
- Deterministic Markdown normalization for final answers (#275) β the employee's final answer goes through a deterministic normalization pass so spacing, lists, and code fences render consistently instead of model-by-model drift. There's a kill-switch to turn it off if you want the raw model output.
- Shopping recommendations render as clickable product cards β when an answer recommends products, they come back as cards you can click, not a wall of links.
A few more things
Models:
- Claude Fable 5 support (migration
V145) β model entries for the latest Claude family member.
Channels:
- Webchat is now Web/API access with multi-session β the embeddable webchat takes an optional
agentIdand asessionIdfor multiple parallel sessions, plus session-management endpoints (list / messages / delete) so an integration can manage its own conversations. - Feishu group @-mention alias learning β the employee learns the aliases a group uses to @-mention it, fixing missed mentions; group sessions now key on the full chatId to avoid suffix collisions.
Reliability:
- MCP cache refreshes on connection change (#289) β adding/removing an MCP server refreshes the affected agents' tool cache, and connecting is non-blocking so a slow server can't stall startup.
- Skill workspace stability β skill workspaces persist on the existing data volume (#273) and non-ASCII skill names no longer collide or move (#255).
- Wiki fixes β page dedup by title with bounded route-prompt growth (#321), correct Chinese path handling in Docker (#260), directory-scan dedup by source path (#272), and the open KB/page now stays in the URL.
- ProgressLedger no longer pins virtual-thread carriers under parallel
progress_update, keeping the scheduler responsive under load.
Full list: git log v1.5.0..HEAD.
Upgrade path
Config is fully compatible. All your agents / skills / wikis / channels / cron / workflows / triggers / goals carry over untouched.
New schema migrates automatically via Flyway. Agent KB scope (V141), wiki transformation target page type (V142), the execute_code tool registration (V143), an MCP production-endpoint fix (V144), Claude Fable 5 entries (V145), and the KB watcher flag (V146) all migrate on first startup; existing databases auto-baseline.
If you're already running v1.5.0 in production:
- Your database doesn't change. MySQL and the H2 desktop default are untouched. PostgreSQL and KingbaseES are new opt-in profiles, not a migration you're forced into β switching engines is a deliberate, fresh-install decision (there's no automatic MySQL β PostgreSQL data migration).
- Vision-in-context is automatic β image follow-ups just start working; no config.
execute_codeis a built-in tool β registered byV143; bind it to an employee like any other tool, and it falls under the same Tool Guard rules.- The global proxy is off until you set it β configure it on the new settings page; with nothing set, outbound behavior is exactly as before.
- Markdown normalization is on with a kill-switch β if a workflow depended on raw model formatting, flip the kill-switch.
What this release means for you
If you're a regular user β
Send a screenshot and keep asking about it β the employee remembers the picture, not just its first description. Ask it to actually compute something and it writes and runs code instead of guessing. Edit who your employee is through a real AGENTS.md editor instead of a raw text box.
If you're building a knowledge base β
One Sources tab per KB: drop in directories with glob patterns, let per-KB auto-sync keep them fresh, and shape page types through a form instead of hand-written JSON.
If you run in a regulated or domestic environment β
Run the whole thing on KingbaseES (人倧ιδ») or PostgreSQL. One PostgreSQL-family migration tree, an opt-in driver that keeps the open-source build clean, and least-privilege database roles in the Docker stack.
If you're a developer β
execute_code for real computation; the webchat session-management endpoints to drive multi-session embeds; a global proxy when your runtime only reaches the world through one.
If you run production β
A new database option for environments that require it, a global proxy for locked-down networks, and a quieter MCP layer that refreshes on connection changes without blocking startup.
One more thing.
Where. Eyes and hands. Self.
An employee you can only run on one database is a tool you have to fit your world around.
An employee that runs on the database your world already requires is one you can actually put to work.
Same with its senses. An employee that forgets the picture after one reply is reading a caption. An employee that keeps the image, looks again on request, and writes code to check its own arithmetic is doing the work, not narrating it.
And the more directly you can say who it is β its context files, its identity, the reach of its knowledge β the less it drifts and the more it's yours.
This release was about meeting the employee where you are: your database, your eyes and hands on the work, your shape on who it becomes.