ZhikunCode: Architecture and Permissions in a Self-Hosted Coding Workbench
Purpose, mechanisms, getting started and boundaries
Source: zhikunqingtao/zhikuncode · zhikunqingtao
User Problem
Positioning and task fitZhikunCode combines conversation, editing, commands, browser capabilities and agent delegation in a self-hosted workbench. Its complexity lies in service coordination and authorization, not just chat UI. Key questions are what the basic Docker deployment provides, when Python capabilities are available and which permissions new sessions use.
- Handle coding tasks through a self-hosted workbench
- Study Java orchestration and Python tool services
- Examine authorization, context recovery and task state
Product Mechanism
Capabilities and execution- Three service layersReact handles interaction, Java owns orchestration and persistence, and Python supplies analysis, browser and HTTP verification. Diagnose service health and capability availability rather than treating a working homepage as proof of full functionality. Source
- A common tool execution pathAuthorization includes frozen input, operation analysis, policy decisions and pre-execution checks. It aims to keep approved and executed parameters aligned, while the documentation notes differences among tool analyzers. Source
- Context recovery has stopping conditionsThe query loop can compress history after context overflow and stop when essential content still cannot fit. Compression is lossy recovery, not unlimited context. Source
- Workspace and execution stateProjects establish trusted directory scope, sessions fix working directories and separate components manage execution and UI recovery. Workspace selection is not an OS sandbox, and cancellation acknowledgement does not prove every process exited. Source
Workflow
Start with a small task- Prepare model access and a directoryUse a tool-capable model and a recoverable practice repository. Check the README’s credential restrictions for the Docker entry point.
- Deploy and inspect healthPreserve an existing .env, configure credentials and WORKSPACE_PATH, then start Compose. Check container status, Java health and actual capability availability.
- Set permissions before the taskOpen the workbench and select a container-visible directory. Change the permission mode first if confirmation is required; do not assume a new session starts restricted.
- Verify changes and persistenceRequest a small fix, inspect the diff and actual test output, then verify state after reconnection. Enable and inspect Python only when its capabilities are needed.
The trial sequence and checks are editorial guidance. Entry commands follow official documentation; this project was not executed for the article. Source
Official entry example
docker compose up -d --build
docker compose ps
curl -fsS http://localhost:8080/actuator/healthComplete the prerequisites above first. Examples contain no real credentials.
Limits and Boundaries
Constraints and selection| Boundary | Meaning | Suggested action |
|---|---|---|
| Full access by default | New sessions default to AUTO_APPROVE, which can approve high-risk operations reaching the authorization stage. Source | Check permissions before the first task and constrain the deployment account’s access. |
| A bundled runtime is not an enabled service | Basic Compose does not start Python; bundled runtime files do not prove those tools are available. Source | Enable through the documented configuration and inspect available and reason fields. |
Scroll horizontally to view the full table
It fits teams willing to maintain multiple services and study authorization and recovery. For a lightweight CLI need, evaluate the operational cost first.
How to Evaluate Adoption
Trial scenario and verificationPilot an input-validation change limited to a practice directory. Compare the displayed diff, actual files and test exit status. If browser verification fails, check Python availability before blaming the page or model. This separates missing deployment capabilities from reasoning failures.
Homepage access, model replies, file edits, tests and browser capabilities require separate checks. Remote deployment also needs the documented ingress authentication and allowed-root configuration.
Evidence: Pinned README · Current repository。
Source fetched (UTC): 2026-11-02T07:26:45.161Z；snapshot commit: c80b9a4e082e。The source date denotes the repository snapshot commit, not the project’s original launch.