Vikunja 2.7.0 is out, a month after 2.6.0, and it is a big one: 856 commits, 317 of them fixes, 62 new features and 58 dependency updates. Six of those fixes are security issues, one high and five medium, and the release asks you to update as soon as you can. Two side effects of the login fix are worth knowing: the desktop app before v2.3.0 will need to log in more often, and instances that serve the frontend and the API from different domains lose cookie-based session refresh.
Task management over MCP
The headline feature is an MCP server, which lets Claude, Codex, Mistral Vibe or any other MCP-speaking assistant work with your instance. Ask for what’s due, create tasks, move things between projects, comment on a task. Setup lives in Settings, then MCP: create a token, pick your client, and Vikunja shows the steps with your instance’s address and the token already filled in. The scoping is the part done well. You can create read-only tokens so the assistant can only look things up, it can do what the token allows and nothing more, and account settings, webhooks and link shares stay off limits entirely.
The new date picker
The old picker looked like it came from a different app and didn’t fit phones. The new one matches the rest of Vikunja: shortcuts like “tomorrow” or “next week,” a time control you can type into or step through, and full keyboard support. It shows up everywhere a date is picked, from due and start dates to reminders, postponing, date-range filters and the Gantt chart. On phones it opens as a sheet from the bottom of the screen.
The quiet work
Servers without a direct internet connection can now route all of Vikunja’s outgoing requests through a proxy, driven by the usual HTTP_PROXY, HTTPS_PROXY and NO_PROXY variables, and the proxy can live on the internal network without turning off the protection against requests to internal addresses. The load testing from last release continued, and the numbers moved: the slowest 1 percent of requests on the same two 4-core servers with 3,000 simulated users went from 260 ms to 22 ms, while CPU usage dropped from 82 percent to about 40. The whole frontend now talks to the server over the v2 API, which the project describes as groundwork for real-time updates in an upcoming release. If you build on the v1 API, the docs have a migration timeline.
My read
Update for the six security fixes alone, and use the read-only token option if an assistant gets anywhere near your tasks. The rest of the release is worth a look because of how it was made: six security fixes, load-test numbers that moved, and the boring groundwork that real-time features need. Projects that publish their load-test numbers and their proxy gaps are projects that expect to be inspected.
Source: the 2.7.0 release post and the 2.7.0 release.