【BUG反馈】新建会话的时候，接口返回错误

[aicloud-cpu]

这个问题不知道怎么产生的，我一直使用分叉会话，所以没有发现。

现在新建会话就会出现这个错误导致新建失败。
/api/session/create

{
    "type": "server-response",
    "rpcId": "f2af4720-04c1-4ec8-a9ab-3a6b10f4cfb8",
    "result": {
        "ok": false,
        "error": {
            "code": "agent-preset/not-found",
            "message": "agent-presets: preset \"code\" not found (available: standard, ptc, minimal, cordis)",
            "details": {
                "agentPreset": "code",
                "available": [
                    "standard",
                    "ptc",
                    "minimal",
                    "cordis"
                ]
            }
        }
    }
}

[m0hamadazzam]

I don't speak Chinese, so I translated your question to understand the issue. I'll reply in English to avoid introducing any ambiguity through translation — I hope that's clear.

From the error response, this looks quite specific:

agent-presets: preset "code" not found
available: standard, ptc, minimal, cordis

The issue appears to be that the new-session request is still asking for the old preset id code.

DeepSeek Harness recently renamed the code preset to ptc. The project intentionally did not keep code as a compatibility alias, so on the current version code is no longer a valid preset id.

If /api/session/create is sending something like:

{
  "agentPreset": "code"
}

change it to:

{
  "agentPreset": "ptc"
}

If you don't specifically need to choose a preset, another option is to omit agentPreset and let the server resolve the configured default preset.

This also seems consistent with your observation that you had been using forked sessions and therefore hadn't noticed the problem before.

The normal session creation path passes the requested agentPreset into the server's preset resolver. If that id doesn't exist, the resolver returns the agent-preset/not-found error shown in your response.

Forking works differently: it derives the preset/composition from the source session rather than relying on the same new-session preset value. So an existing session using a valid or inherited preset can continue to fork successfully while creating a fresh session fails because the client is still sending code.

I would check this first:

1. Open DevTools → Network.
2. Create a new session.
3. Inspect the request to /api/session/create.
4. Check whether the payload contains "agentPreset": "code".

If it does, that should be the root cause.

If the request already contains "agentPreset": "ptc" or doesn't specify agentPreset at all, then this diagnosis would not apply, and it would be useful to see the actual request payload as well.