Understand your workspace.

Look up how Prokop works, from workspace behavior to configuration and commands. For a first session, follow Get started. For a specific task, use the how-to guides.

Start here

Get started →Install, connect a model, start your first session. Two commands total.How-to guides →Complete a specific task with a short video and written steps.

Core concepts

Workspaces & sessions →Projects, session board, capabilities, memory, skills, goal mode, workflows, preconfigs.Tools →Built-in coding tools, capability tools, MCP tools, writing your own.Client & mobile →Web client, PWA on your phone, browser extension.

Reference

Configuration →Providers, models, environment variables, compaction, preconfig setup.CLI reference →Daemon, models, database, migration, and update commands.Security & auth →Token auth, TLS, tool permissions.

Common questions

What is Prokop?

An open-source agentic coding workspace. One binary runs a local daemon with the full web client inside: sessions, projects, files, diffs, terminals, permissions, memory, and scheduled work. You drive it from any browser, desktop or phone.

Where does everything live?

~/.prokopai/ - server data, database, preconfigs, models
<project>/.prokopai/ - workspace memory and MCP configuration
<project>/AGENTS.md - instructions the agent loads for that project
<project>/.agents/skills/ - workspace skills

Your project context and local database stay on disk under paths you control.

Do I need to edit config files?

No. Models and credentials can be connected in the client under Configuration. API keys, OAuth subscriptions, model selection, workspace capabilities: all UI. API keys can also live in .env, alongside server settings such as the auth token or TLS.

Can I use it from my phone?

Yes. The client is mobile optimized and served by your daemon: same sessions, same agents, same permissions, reorganized for one surface at a time. Open it over your private network, or use networking you choose such as Tailscale. PWA installation from another device normally requires HTTPS, which the built-in TLS listener can provide.

What about security?

By default there is no auth: the daemon trusts its network, fine for localhost and private networks. Expose it further and you set a single auth token in .env. Separately, actions involving sensitive files, access outside the workspace, deletions, or dangerous commands ask for approval, with scopes you can revoke.