ai-sandbox-daytona: spawn().stdin.end() is a no-op while writableStdin: true, so stdin-fed harnesses (Claude Code, Codex) hang forever
Maintainer thường phản hồi trong vòng 1 ngày
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 3/5
- Thời gian dự kiến
- 1-2 ngày
- Mức phù hợp với người mới
- 64/100
- Loại issue
- Lỗi
- Độ rõ ràng
- Khá rõ ràng
- Mức độ hoạt động
- Sôi nổi
- Công nghệ
- typescript
Hướng nghiên cứu
Start by reading the Daytona spawn handle used by spawnNdjson and startJournaledAgent in ai-sandbox, then check how the Daytona API handles closing stdin and what tests cover stdin writes. Confirm that ending stdin delivers EOF and lets stdin-fed processes finish; the issue is resolved when the reproduction no longer hangs.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
TanStack AI version
1.0.0
Framework/Library version
React 19
Describe the bug and the steps to reproduce it
What happens
On a Daytona sandbox, a Claude Code run never starts working. claude -p starts, writes its config, and then waits with no output until the run is aborted. The claude process stays alive in the sandbox afterwards, because killableProcesses is false. Codex takes the same stdin path, so it hangs the same way.
Cause
DAYTONA_CAPS.writableStdin is true, so the harnesses send the prompt through stdin. spawnNdjson and startJournaledAgent in ai-sandbox call proc.stdin.write(input) and then proc.stdin.end(). Daytona's spawn handle implements end as a no-op:
stdin: {
write: (data) =>
this.sandbox.process.sendSessionCommandInput(sessionId, cmdId, data),
end: () => Promise.resolve(),
},
sendSessionCommandInput delivers the bytes, but EOF never arrives. claude -p and codex exec read stdin to EOF before they begin, so they wait forever.
Minimal reproduction
import { daytonaSandbox } from "@tanstack/ai-sandbox-daytona";const provider = daytonaSandbox({ apiKey: process.env.DAYTONA_API_KEY });
const h = await provider.create({} as never);
const read =node -e "let s='';process.stdin.on('data',d=>s+=d).on('end',()=>console.log(s))";// 1. Through stdin: never exits.
const p = await h.process.spawn(read, {});
await p.stdin.write("hello");
await p.stdin.end();
console.log(await Promise.race([
p.wait().then((c) =>exit ${c}),
new Promise((r) => setTimeout(() => r("still waiting after 20s"), 20_000)),
])); // -> "still waiting after 20s"
// 2. Through a file redirect: exits at once.
await h.fs.write("/tmp/prompt", "hello\n");
const q = await h.process.spawn(${read} < /tmp/prompt, {});
console.log(await q.wait()); // -> 0, prints "hello"
Measured on a real Daytona sandbox (daytonaio/sandbox:0.8.0): case 1 was still waiting after 20 s, and case 2 exited 0 in about 2.4 s.
Affected harnesses
| Harness | How the prompt is passed | On Daytona |
|---|---|---|
| ai-claude-code | stdin (claude -p) | hangs |
| ai-codex | stdin | hangs |
| ai-grok-build (NDJSON) | argv (-p "") | not affected |
| ai-opencode | HTTP to opencode serve via ports.connect | not affected |
Suggested fix
Either of these would fix it:
- Set
writableStdin: falsefor Daytona until EOF can be delivered. The harnesses already have this path: they write the prompt to a file and run… < file, and it works on Daytona today. This is the smallest change. - Implement
end()for real, if the Daytona session API can close a command's stdin (for example, a PTY session, which #1085 mentions). If it cannot,writableStdin: trueshould not be advertised.
A test for whichever fix is chosen: spawn a process that reads stdin to EOF, then write and end, and assert that it exits.
Workaround
We wrap the provider so that it and its handles report writableStdin: false:
const handleWithoutStdin = (h: SandboxHandle) =>
Object.defineProperty(h, "capabilities", {
value: { ...h.capabilities, writableStdin: false },
});
// applied to provider.capabilities(), create(), resume(), restoreSnapshot()
After this, ai-claude-code takes the prompt-file path, and the prompt reaches the CLI.
Related: #1085 (session stdin, PTY kill).
Your Minimal, Reproducible Example - (Sandbox Highly Recommended)
Code Sanbox
Screenshots or Videos (Optional)
No response
Do you intend to try to help solve this bug with your own PR?
None
Terms & Code of Conduct
- I agree to follow this project's Code of Conduct
- I understand that if my bug cannot be reliable reproduced in a debuggable environment, it will probably not be fixed and this issue may even be closed.
- Ngôn ngữ chính
- TypeScript
- Star
- 3.2k
- Fork
- 372
- Merge trung bình
- 1 ngày 14 giờ
- Pull request đã merge (30 ngày)
- 241
Chuẩn bị môi trường
- Không có Dockerfile hay tệp Docker Compose
- Có mẫu pull request
- Đọc hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của TanStack/ai
-
openai-base: a Responses max_output_tokens cutoff ends as RUN_ERROR without usage instead of finishReason 'length'Có thể đã có người làm @pcbeingused333 đã nhận hôm nay. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 74/100
TanStack/ai#1916 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 58/100
TanStack/ai#1924 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
ai-vercel-gateway: usage.cost leaves out gateway surcharges, and the BYOK credential type is not exposedCó thể đã có người làm Có pull request liên kết đang mở hoặc đã được merge. Đang mở
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 55/100
Maintainer thường phản hồi trong vòng 1 ngày
-
ai-gemini: native image generation throws "returned no id" when modelOptions.store is falseCó thể đã có người làm @pcbeingused333 đã nhận hôm nay. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 57/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Durable resume through withPersistence never fills ctx.inputResponse for mcp_input interruptsCó thể đã có người làm @tombeckenham đã nhận 5 ngày trước. Đang mởwaiting-on: maintainer
TanStack/ai#1885 · 1 người được giao ·
Maintainer thường phản hồi trong vòng 1 ngày
Issue tương tự
-
bug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 82/100
scaleway/ultraviolet#7089 ·
Maintainer thường phản hồi trong vòng 2 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 67/100
tencent-connect/dsh-qqbot#81 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
[Bug]: Pen taps on sidebar rows start a drag and lose their clickCó thể đã có người làm @makhnatkin đã nhận hôm nay. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 62/100
Maintainer thường phản hồi trong vòng 1 ngày
-
bug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 66/100
clangd/vscode-clangd#1009 ·