Codex desktop: send_message_to_thread fails with "'sendRequest.bind' is not a function"
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 78/100
- Issue type
- Bug
- Clarity
- Clearly specified
- Activity status
- Active
- Tech stack
- javascript
- Domain
- desktop-dev
Research direction
Find the implementation of the mcp__codex_app__send_message_to_thread MCP tool in the desktop app codebase. The error 'sendRequest.bind' is not a function means sendRequest is not a function where .bind() is called. Check how sendRequest is imported or passed to the tool handler and correct the reference. Verify with the desktop app's test suite.
Written by the indexing model from the issue text.
Description
What version of the Codex App are you using (From “About Codex” dialog)?
26.1002.51308 (build 13417), read from the installed desktop application's Info.plist
What subscription do you have?
Not collected for this sanitized report
What platform is your computer?
macOS 26.4 (25E246), arm64
What issue are you seeing?
From a side conversation of an active local Codex task, all observed calls to mcp__codex_app__send_message_to_thread failed with:
'sendRequest.bind' is not a function.
Captured tool result:
{
"isError": true,
"texts": ["'sendRequest.bind' is not a function."]
}
list_threads and read_thread succeeded for the same local task. The target existed and was active. No successful delivery receipt was returned, and a subsequent thread read did not show the intended message.
This prevents a side-conversation assistant from delivering an explicitly authorized follow-up to the main task.
What steps can reproduce the bug?
- Open a side conversation of an existing active local Codex task.
- Explicitly authorize the assistant to send a short follow-up message to the main task.
- Call the exposed
mcp__codex_app__send_message_to_threadtool with an existing task ID and a normal text prompt:
{
"threadId": "<existing-main-thread-id>",
"hostId": "local",
"prompt": "Please review the consumer-coverage checklist when appropriate."
}
- Observe the tool error.
- Retry with
hostIdomitted or with a shorter prompt. The same error occurs. - Read the target thread to check whether the follow-up was delivered; no intended message was observed.
Real session and thread IDs are omitted from this public report.
What is the expected behavior?
The follow-up should be delivered or queued in the specified existing task, and the tool should return an accurate success receipt.
Additional information
Observed on 2026-10-08. Installed codex-app-tools plugin cache version: 0.1.5.
The internal root cause is unknown; this report establishes the observed repeatable execution failure. No desktop restart, permission changes, plugin changes, project-code changes, or task-state changes were made to work around it.
This report excludes real thread IDs, project code, business data, credentials, and full conversation logs. A public issue search for repo:openai/codex "sendRequest.bind" returned no results before submission.
- Dominant language
- Rust
- Stars
- 129k
- Forks
- 20.3k
- Avg merge
- 1m
- Merged PRs (30d)
- 998
Getting set up
- No Dockerfile or Docker Compose file
- No pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from openai/codex
-
app bug
Difficulty 2/5 1-3 hours Newbie friendliness 67/100
Maintainers usually reply within 1 day
-
app-server documentation
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
Maintainers usually reply within 1 day
-
app bug
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
openai/codex#55328 · 1 comment ·
Maintainers usually reply within 1 day
-
bug CLI
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
openai/codex#55122 · 2 comments ·
Maintainers usually reply within 1 day
-
Python SDK: CodexClient.close() leaves the app-server's stdout/stderr pipes open (and never waits after kill)Possibly taken @akhil9tiet claimed this 2 days ago. Openapp-server bug
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
openai/codex#54908 · 2 comments ·
Maintainers usually reply within 1 day
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 66/100
home-assistant/installer#308 ·
Maintainers usually reply within 1 day
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
swc-project/swc-next#1053 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 67/100
linebender/resvg#1179 · 1 comment ·
Maintainers usually reply within 2 days
-
enhancement triage
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
zizmorcore/zizmor#2468 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 64/100
Maintainers usually reply within 2 days