CommandCodeAI / CommandCodeAI/command-code
/learn-taste learns nothing from Codex sessions: extractor only reads legacy event_msg/user_message format
Nobody has claimed this yet.
- Dominant language
- No language data
- Stars
- 4k
- Forks
- 350
- PR merge metrics
- No merged PRs in 30d
Description
What happens
/learn-taste (and cmd learn-taste) finds my Codex sessions but learns nothing from them. Taste onboarding ends with "TASTE Skipped", and ~/.commandcode/taste/ stays empty. Projects whose history is Codex-only get zero taste signal.
Environment
- Command Code v1.53.1 (
command-codenpm global,cmdc), Windows 11, PowerShell - Codex CLI 0.154.0, sessions at
~/.codex/sessions/YYYY/MM/DD/rollout-*.jsonl
Root cause: stale Codex prompt extractor
The session finder works (3-level YYYY/MM/DD walk + rollout-*.jsonl + session_meta.payload.cwd project match). But extractCodexPrompts only accepts lines shaped as:
{ "type": "event_msg", "payload": { "type": "user_message", "message": "..." } }
That shape no longer exists in Codex rollouts. Verified on this machine:
- Newest rollout (Sept 2026): 165 lines, 62
event_msg, 0 withpayload.type: "user_message".event_msgpayloads are onlyitem_completed,token_count,task_started,task_complete. - Search for
"user_message"across all September rollouts: 0 hits. A May 2026 archived rollout: also 0. - Conversation turns now live in
response_itementries:
{ "type": "response_item", "payload": { "type": "message", "role": "user", "content": [{ "type": "input_text", "text": "..." }] } }
(role is user / assistant / developer; user text parts use type: "input_text", assistant uses output_text.)
So extraction always yields [] → nothing to learn.
Suggested fix
In extractCodexPrompts, also handle type: "response_item" with payload.type: "message" and payload.role: "user", joining payload.content[].text for input_text parts. (Note: some role: "user" items are injected context like <environment_context> / skills text — you may want to skip those or let the taste model filter them.)
Secondary issue: case-sensitive cwd match on Windows
The project filter compares session_meta.payload.cwd === projectPath exactly. On Windows, recorded cwd case varies between sessions (e:\development\... vs E:\development\...), so matches are silently missed. Suggest case-insensitive comparison + separator normalization on win32.
Repro
- Have Codex-only history in a project (any recent Codex CLI).
- Run
cmdc, then/learn-taste(orcmdc learn-taste) from that project dir. - Observe: sessions are scanned, but no taste is learned.
Contributor guide
No contributing guide indexed for this repository
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.
Research direction
Start at extractCodexPrompts and trace the session handling used by /learn-taste and cmd learn-taste. Handle user messages in response_item entries, then inspect the session_meta.payload.cwd project filter for Windows case and separator differences. Done means recent Codex-only sessions produce taste input and matching project paths are not silently skipped on Windows.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- node.js
- Domain
- cli
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 72/100