bug: quiet mode outputs duplicate messages

What version of Codex is running?

v0.1.2504221401

Which model were you using?

gpt-4o

What platform is your computer?

Darwin 24.1.0 arm64 arm

What steps can reproduce the bug?

Run

codex -q "explain this codebase to me"  

What is the expected behavior?

I expect that any output message should be printed once

What do you see instead?

Any output message is printed 3x. For example, when I run

codex -q "explain this codebase to me"  

on the codex codebase, I get:

{
  "role": "user",
  "content": [
    {
      "type": "input_text",
      "text": "explain this codebase to me"
    }
  ],
  "type": "message"
}
{
  "id": "msg_68096a9c0af081919b3fd7504216d7840c5829f642c2ebf9",
  "type": "message",
  "status": "completed",
  "content": [
    {
      "type": "output_text",
      "annotations": [],
      "text": "To explain the codebase, I'll need to first look at its structure and specific files. I'll start by gathering general information about the project to give you an overview.\n\nLet me do that now."
    }
  ],
  "role": "assistant"
}
{
  "id": "msg_68096a9c0af081919b3fd7504216d7840c5829f642c2ebf9",
  "type": "message",
  "status": "completed",
  "content": [
    {
      "type": "output_text",
      "annotations": [],
      "text": "To explain the codebase, I'll need to first look at its structure and specific files. I'll start by gathering general information about the project to give you an overview.\n\nLet me do that now."
    }
  ],
  "role": "assistant"
}
{
  "id": "fc_68096a9ce8248191aa7d562824eb6d540c5829f642c2ebf9",
  "type": "function_call",
  "status": "completed",
  "arguments": "{\"command\":[\"rg --files\"]}",
  "call_id": "call_RO4xttbxlBDoK5xdboKuBEiq",
  "name": "shell"
}
{
  "id": "msg_68096a9c0af081919b3fd7504216d7840c5829f642c2ebf9",
  "type": "message",
  "status": "completed",
  "content": [
    {
      "type": "output_text",
      "annotations": [],
      "text": "To explain the codebase, I'll need to first look at its structure and specific files. I'll start by gathering general information about the project to give you an overview.\n\nLet me do that now."
    }
  ],
  "role": "assistant"
}
{
  "id": "fc_68096a9ce8248191aa7d562824eb6d540c5829f642c2ebf9",
  "type": "function_call",
  "status": "completed",
  "arguments": "{\"command\":[\"rg --files\"]}",
  "call_id": "call_RO4xttbxlBDoK5xdboKuBEiq",
  "name": "shell"
}
{
  "type": "function_call_output",
  "call_id": "call_RO4xttbxlBDoK5xdboKuBEiq",
  "output": "{\"output\":\"aborted\",\"metadata\":{}}"
}
{
  "type": "message",
  "role": "user",
  "content": [
    {
      "type": "input_text",
      "text": "No, don't do that — keep going though."
    }
  ]
}
{
  "id": "msg_68096a9dde38819189e52e1fbc0868dc0c5829f642c2ebf9",
  "type": "message",
  "status": "completed",
  "content": [
    {
      "type": "output_text",
      "annotations": [],
      "text": "Understood. I'll outline a general strategy for explaining the codebase:\n\n1. **Project Structure:** \n   - Identify key directories and files, such as `src`, `tests`, `README.md`, etc.\n\n2. **README and Documentation:**\n   - Check for a `README.md` or similar file for an overview, usage instructions, and key features.\n\n3. **Key Components:**\n   - Review main application files to understand core functionality.\n   - Check for configuration files such as `.env` for environment variables or `config.json` for application settings.\n\n4. **Dependencies:**\n   - Examine `package.json`, `requirements.txt`, or similar files for libraries and dependencies.\n\n5. **Tests:**\n   - Look at the `tests` directory or testing scripts to understand how the project ensures quality.\n\n6. **Build/Deployment:**\n   - Check for build scripts, Dockerfiles, or CI/CD configurations for deployment details.\n\n7. **Code Style and Guidelines:**\n   - Look for linting or formatting configurations such as `.eslintrc`, `.prettierrc`, etc.\n\nOnce I have this information, I can provide a detailed summary. Let me know if you want me to focus on specific parts or explore the codebase further."
    }
  ],
  "role": "assistant"
}
{
  "id": "msg_68096a9dde38819189e52e1fbc0868dc0c5829f642c2ebf9",
  "type": "message",
  "status": "completed",
  "content": [
    {
      "type": "output_text",
      "annotations": [],
      "text": "Understood. I'll outline a general strategy for explaining the codebase:\n\n1. **Project Structure:** \n   - Identify key directories and files, such as `src`, `tests`, `README.md`, etc.\n\n2. **README and Documentation:**\n   - Check for a `README.md` or similar file for an overview, usage instructions, and key features.\n\n3. **Key Components:**\n   - Review main application files to understand core functionality.\n   - Check for configuration files such as `.env` for environment variables or `config.json` for application settings.\n\n4. **Dependencies:**\n   - Examine `package.json`, `requirements.txt`, or similar files for libraries and dependencies.\n\n5. **Tests:**\n   - Look at the `tests` directory or testing scripts to understand how the project ensures quality.\n\n6. **Build/Deployment:**\n   - Check for build scripts, Dockerfiles, or CI/CD configurations for deployment details.\n\n7. **Code Style and Guidelines:**\n   - Look for linting or formatting configurations such as `.eslintrc`, `.prettierrc`, etc.\n\nOnce I have this information, I can provide a detailed summary. Let me know if you want me to focus on specific parts or explore the codebase further."
    }
  ],
  "role": "assistant"
}
{
  "id": "msg_68096a9dde38819189e52e1fbc0868dc0c5829f642c2ebf9",
  "type": "message",
  "status": "completed",
  "content": [
    {
      "type": "output_text",
      "annotations": [],
      "text": "Understood. I'll outline a general strategy for explaining the codebase:\n\n1. **Project Structure:** \n   - Identify key directories and files, such as `src`, `tests`, `README.md`, etc.\n\n2. **README and Documentation:**\n   - Check for a `README.md` or similar file for an overview, usage instructions, and key features.\n\n3. **Key Components:**\n   - Review main application files to understand core functionality.\n   - Check for configuration files such as `.env` for environment variables or `config.json` for application settings.\n\n4. **Dependencies:**\n   - Examine `package.json`, `requirements.txt`, or similar files for libraries and dependencies.\n\n5. **Tests:**\n   - Look at the `tests` directory or testing scripts to understand how the project ensures quality.\n\n6. **Build/Deployment:**\n   - Check for build scripts, Dockerfiles, or CI/CD configurations for deployment details.\n\n7. **Code Style and Guidelines:**\n   - Look for linting or formatting configurations such as `.eslintrc`, `.prettierrc`, etc.\n\nOnce I have this information, I can provide a detailed summary. Let me know if you want me to focus on specific parts or explore the codebase further."
    }
  ],
  "role": "assistant"
}

Additional information

Note that the same message id is being output thrice