Open source · MIT
QTask
Tell it what you want done, in ordinary words.
An AI-first task manager: create projects, break down work and update status by saying so in plain language — with a proper interface underneath for nested projects, subtasks and shared work, and an MCP server so Claude or Cursor can work on the same projects.
Say what you want done
QTask is a task manager built around an AI agent rather than one that had a chatbot added to it later. Agent is a view in the header, beside Projects and Tasks, and it is a legitimate way to do the work — not a novelty next to the real interface.
You talk to it the way you would talk to a colleague:
→ create project Kitchen Reno
→ Create project Garden and add tasks: Plan layout, Buy soil, Plant herbs
→ Mark Schedule inspection as done
→ get me tasks for current projectCompound requests work in one message — a project and its sub-project, or a project and several tasks at once — or step by step if you would rather approve each piece separately. Each conversation is a session you can leave and come back to, so a train of thought about one piece of work stays together instead of scrolling away.
It proposes; you decide
This is the part that makes an AI-first task manager trustworthy enough to actually use. Write actions — creating or updating tasks, sharing them, creating projects — arrive as proposals. They collect in a Pending approval bar, and nothing changes until you approve. Reject and it never happened.
Read actions — search, fetch a task, list projects, summarise — just run. There is nothing to approve about being told something, and gating reads would make the agent tedious for the thing you do most.
If you would rather it simply got on with it, Auto-approve agent actions in the account menu applies writes as they come, and you can still reject them afterwards. The default is the cautious one.
Approve a new project and QTask offers to switch your active project to it, so the next thing you say lands where you meant it to.
A real interface, not just a chat box
Everything the agent does, you can do by hand — and the structure it works in is a proper one. Projects nest under projects in a parent/child tree you can drag and reparent. Tasks live in one or more projects and carry subtasks, which can nest inside each other in turn.
| Concept | What it is |
|---|---|
| Project | A workspace grouping related work. Projects nest under other projects. |
| Task | A work item. Lives in one or more projects, and can hold nested subtasks. |
| Subtask | A breakdown item inside a task — or inside another subtask. Inherits context from its parent. |
| Step | A checklist line on a task or subtask. Use steps for simple to-do lines; use subtasks when you need status, progress or further nesting. |
Most work is scoped to your active project, which is what both the Tasks view and the agent operate inside — so "add a task" is unambiguous without you naming the project every time. There is also search that finds a task by what it meant rather than the words you happened to type, comments, progress rollups, keyboard shortcuts and expense tracking.
Shared work, with roles that mean something
Every project has an owner and optional collaborators, and you can watch work you do not own without being able to disturb it. Five roles draw the lines:
| Role | Can |
|---|---|
| Viewer | See the project and its tasks |
| Executor | See it, update task status, and comment |
| Editor | Create and edit tasks, and delete their own |
| Manager | Create sub-projects, edit and move the project, rearrange structure — but not delete it or manage its members |
| Owner | Everything, including deleting the project and managing who is on it |
Invite someone from the Members panel by email or from a recent-collaborator list; they accept by email link or the notification bell. Inviting on a parent project cascades the same role to every sub-project beneath it. Projects where you are a manager are tinted in the project tree with an amber dot, so a permission you did not expect is visible before you run into it rather than after.
Or drive it from Claude
The built-in agent is not the only way in. QTask ships an MCP server, so Claude Desktop, Cursor or any MCP client can work on the same projects and tasks as first-class operations — discovered on connection, not scraped out of a web page.
The same rule applies there: writes proposed by an external model are staged for your
approval. Access is a key you issue and can revoke, not an ambient capability — every API
route except /health and /api/auth/* requires a bearer token,
including the MCP surface.
For hosted qtask.dev, create an MCP API key under Account menu → External AI
(MCP) and run the bridge. For a local install, copy your JWT from the web client
and set MCP_JWT in your client's MCP config —
mcp-config.example.json in the repository is a working starting point.
npm run mcp # MCP stdio server — local dev / Cursor
npm run mcp:bridge # stdio bridge to the hosted /api/mcpYour data, and whose model
QTask is self-hostable end to end, and the AI backend is pluggable. Run it against a local Ollama and nothing leaves the building — including the embeddings behind semantic search, which are generated locally by default.
ollama pull qwen3.5:2b
ollama pull nomic-embed-text
docker compose up -d
cp .env.example .env # set JWT_SECRET
npm install
npm install --prefix client
npm run dev:all # API :3000 · web client :5173
Create an account on first visit. Local secrets belong in .env.local, which
overrides .env and is not committed; on a production server they go in
.env.
Read further
- User guide — projects, tasks, the agent, sharing, search, shortcuts. Start here.
- MCP guide — for Claude Desktop and Cursor: API keys, OAuth, staging.
- Deployment guide — local and production deployment.
- Product specification — the full requirements document.
Signed-in users can open Help from the account menu in the web app.