Downcity
Configuration

Project Configuration (downcity.json)

Most-used project-level fields and practical cautions

Project Configuration (downcity.json)

downcity.json is the project runtime entrypoint.

{
  "name": "my-agent",
  "execution": {
    "type": "acp",
    "agent": {
      "type": "kimi"
    }
  },
  "start": {
    "host": "127.0.0.1",
    "port": 5314
  },
  "services": {}
}

Cautions

  1. A project now must declare execution, and the mode is api, acp, or local.
  2. execution.type="acp" switches session execution to an ACP coding agent. Current supported values are codex, claude, and kimi.
  3. start.host/start.port affects default CLI routing.
  4. Keep project-level config in downcity.json, including services and plugins.
  5. Local shell / CLI commands now always run inside a sandbox. Top-level sandbox only adjusts the boundary.

Execution Modes

If you want to use the console-global model pool:

{
  "execution": {
    "type": "api",
    "modelId": "default"
  }
}

If you want the project to use a GGUF file from ~/.models directly:

{
  "execution": {
    "type": "local",
    "local": {
      "model": "gemma-4-E4B-it-UD-Q4_K_XL.gguf"
    }
  }
}

If you want chat/task sessions to run through an external coding agent instead of the model execution path:

{
  "execution": {
    "type": "acp",
    "agent": {
      "type": "kimi"
    }
  }
}

Currently supported:

  • kimi: defaults to kimi acp
  • claude: defaults to npx -y @zed-industries/claude-code-acp
  • codex: defaults to npx -y @zed-industries/codex-acp

Override the launch command when your local installation differs:

{
  "execution": {
    "type": "acp",
    "agent": {
      "type": "codex",
      "command": "codex-acp",
      "args": []
    }
  }
}

Current scope:

  • execution.type="acp" only changes the session/chat/task execution path.
  • execution.type="api" requires execution.modelId to exist in the console model pool.
  • execution.type="local" reads local-model and llama settings from plugins.lmp, defaults to ~/.models, and requires a working llama-server.

Shell Sandbox

In the current version, shell / CLI commands always run inside a sandbox. Project-level sandbox only adjusts the boundary:

{
  "sandbox": {
    "networkMode": "off",
    "writablePaths": [".", ".downcity"],
    "envAllowlist": ["PATH", "LANG", "TERM", "SHELL"]
  }
}

Current behavior:

  • Affects both the shell service path and kind=script task execution
  • Current first-class backend is macOS using built-in sandbox-exec
  • Sandbox cannot be disabled and shell execution does not fall back to an unrestricted host process
  • Host paths not mounted into the sandbox are not visible
  • writablePaths must stay inside the project root
  • Network is open by default; omitting the field behaves like networkMode="full"
  • networkMode="off" blocks network access
  • networkMode="restricted" is currently handled the same as open network
  • networkMode="full" allows network access from shell commands

Common commands

city config get
city config get execution
city config set start.port 3100