panes create --initial-input-file / --prompt pastes into the Claude composer but never submits

[genzrebuilds]

panes create --initial-input-file / --prompt pastes into the Claude composer but never submits

Summary

When creating a Claude-agent pane with initial input, the text is pasted into the
Claude Code composer but Enter is never sent. The panel reports ready and then sits
idle indefinitely with the prompt staged in the composer. An orchestrating agent that
trusts --wait-ready + initial input will believe work has started when nothing is
running.

Environment

• RunPane wrapper: 2.4.5 (npm, node runtime, linux x64)
• Pane app: 2.4.5 (packaged, Electron 37.6.0, node 22.19.0)
• Agent: claude → claude --dangerously-skip-permissions (Claude Code 2.1.197)
• Transport: unix socket daemon

Exact command

runpane panes create --repo my-app \
  --name "pr-1234-review" \
  --agent claude \
  --source agent --no-focus \
  --initial-input-file /tmp/prompt-pr-1234.txt \
  --wait-ready --ready-timeout-ms 60000 \
  --yes --json

(/tmp/prompt-pr-1234.txt was a ~15-line multi-line review prompt. Reproduced
identically across 11 panes created sequentially this way.)

Expected behavior

Initial input is delivered to the agent CLI and submitted, so the agent starts
working — or, if auto-submit is intentionally not performed, the JSON result should
say so (e.g. initialInput: "staged") and nextCommand should point at
panels submit-composer.

Actual behavior

• Creation JSON: readiness.matched: true, state.isCliReady: true,
  activityStatus: "active" at creation, then the panel goes idle.

• panels output / panels screen show only the shell launch line — no agent
  activity. lastActivity stays frozen at the creation timestamp.

• The prompt text was in fact sitting in the Claude composer: running

  runpane panels submit-composer --panel <panel-id> --strategy auto --yes --json

  returned {"inputBytes": 1, "strategy": "enter", "sequenceName": "enter-cr", "verifiedSubmitted": true} and the agent immediately started working.
  This was required on all 11 panes; all fixed by a single Enter.

Observed JSON (creation, trimmed)

{
  "ok": true,
  "readiness": {
    "ok": true,
    "condition": "ready",
    "matched": true,
    "elapsedMs": 501,
    "state": {
      "initialized": true,
      "activityStatus": "active",
      "isCliReady": true,
      "isCliPanel": true,
      "agentType": "claude"
    }
  }
}

Minutes later, panels wait --for idle matched instantly with lastActivity
unchanged from creation time — i.e. the agent never received a submitted prompt.

Root-cause hypothesis

Initial input is written to the PTY as plain text (paste) with no trailing submit
sequence, or the paste lands as a bracketed paste that Claude Code's composer holds
for confirmation. Since submit-composer --strategy auto resolves to a bare
enter-cr and verifies success, the missing piece is just the submit keypress after
the initial-input paste — likely a race: input may be sent before the TUI composer is
ready to treat Enter as submit, or the submit was never wired for the initial-input
path.

Suggested next steps

1. After delivering initial input to a CLI panel, run the same verified-submit logic
   as panels submit-composer --strategy auto (it already exists and works).
2. Surface the result in the creation JSON, e.g.
   initialInput: {delivered: true, submitted: true|false}.
3. If auto-submit is deliberately withheld, document it and emit a nextCommand
   of panels submit-composer ... so orchestrating agents don't stall.

Impact

Any agent-driven fan-out (create N background panes with prompts, wait for results)
silently deadlocks: every pane looks "ready" and "idle", and no work ever starts
until something presses Enter. Workaround for orchestrators today: always follow
panes create --initial-input-file with panels submit-composer --strategy auto and
check verifiedSubmitted: true.

[parsakhaz]

Reopening based on a fresh user report from StriderV on July 20: after continuing to test the now-working RunPane flow, the next blocker is that sending a prompt to Claude with the runpane submit command fills the Claude input box but does not actually submit it. This appears to reproduce the core symptom of this issue on a current build, or expose an incomplete fix in the direct submit path. We should confirm the exact CLI command, version, and environment and test both the panels submit --text path and initial-input delivery against current Claude Code before deciding whether this is a regression or a distinct command-path bug.

[parsakhaz]

Opened PR #351 to close this: #351

Status: branch is rebased on origin/main and pushed. The fix routes Claude direct submit and wait-ready initial input through the verified composer-submit path, surfaces initialInput/submission verification fields, and makes the Node/Python wrappers fail unverified direct submits. Local verification passed under Node v22.23.1: focused runpane IPC tests, runpane contract checks, typecheck, and lint. Not merged or released.