anthropics
"Plan mode" not working as expected.
My expectation was to have some /readonly mode.
In Aider it's command /ask that's why I used that name in #1946 .
I was pointed that [Shift]+[Tab] switching to "Plan Mode" is Claude Answer,
and that was used as argument to clause #1946 .
However it is not.
Semantics is different.
I have no way to force Claude in Plan mode to behave and asnwer like in normal mode, instead it's trying to answer with a plan in a way it wants instead of collaborating with me like in normal mode.
Overall, This is good things in plan mode. When I WANT to use this feature and use Plan Mode then it's great.
However very very very often I want /readonly (in Aider /ask ) mode. As Claude Code is Agentic and can do Tool calling we need for this also #2058 to be implemented.
Therefore please reconsider /readonly command and consider reopening #1946 .
One of many many examples I could give:
In normal mode I am getting formatting I requested for my question showing me options as I requested etc...:
normal mode
● Analysis Summary
Current trigger patterns:
- 3 workflows trigger on [push, pull_request, workflow_dispatch] (broad)
- 2 workflows trigger on specific branches only
- All workflows run on every push/PR regardless of commit message
Minimal Implementation
Add if condition to skip jobs when commit message starts with "META". Here's the most efficient approach:
Option 1: Job-level condition (recommended)
jobs:
job_name:
if: "!startsWith(github.event.head_commit.message, 'META')"
# ... rest of job
Option 2: Workflow-level condition
on:
push:
branches: [master, foobar/*]
pull_request:
branches: [master, foobar/*]
jobs:
job_name:
if: "!startsWith(github.event.head_commit.message, 'META')"
The job-level condition is preferred because:
- Minimal change (1 line per job)
- Works for both push and PR events
- Skips runner allocation entirely
- Preserves existing trigger logic
For workflows with multiple jobs, add the condition to each job that should be skipped.
planning mode
In planning mode it follows it's own wish and prefernce how to format and acutally is not even providing me comparison of options as I requested:
╭─────────────────────────────────────────────────────────────────────────────────────────────────────────────────╮
│ Ready to code? │
│ │
│ Here is Claude's plan: │
│ ╭─────────────────────────────────────────────────────────────────────────────────────────────────────────────╮ │
│ │ Implementation Plan for Skipping META Commits │ │
│ │ │ │
│ │ Recommended Approach: Use job-level conditional with if: "!startsWith(github.event.head_commit.message, │ │
│ │ 'META')" │ │
│ │ │ │
│ │ Steps: │ │
│ │ 1. Add the if condition to each job in all 6 workflow files │ │
│ │ 2. Test with a META commit to verify workflows are skipped │ │
│ │ 3. Optional: Add concurrency control for additional optimization │ │
│ │ │ │
│ │ Alternative considered: Using [skip ci] pattern, but would require changing META commit format which breaks │ │
│ │ existing conventions. │ │
│ │ │ │
│ │ Files to modify: │ │ (...)
│ │ │ │
│ │ Ready to implement? │ │
│ ╰─────────────────────────────────────────────────────────────────────────────────────────────────────────────╯ │
│ │
│ Would you like to proceed? │
│ │
│ ❯ 1. Yes │
│ 2. No, keep planning │
│ │
╰─────────────────────────────────────────────────────────────────────────────────────────────────────────────────╯
semantics of Planning Mode and Readonly modes is different and both should be possible
planning is greate to refine instructions what to do before execution, and I use it a lot ! So please don't change this feature ;).
Still SEMANTICS of "Planning mode" versus "/readonly" modes is different, so those should be separate options.
Still readonly mode would be helpful....
Or now I realise that we could make it (and #1946 ) more flexible and allow users to define in settings own "modes" types,
so user in json could define:
(...)
"modes": {
"ReadonlyLocal": { "allowed": ["Read"....] ... "denied": "Write"...}
"ReadonlyAndWeb": { "inherit_permissions":["ReadonlyLocal",...], "allowed": ["WebFetch"...}...}
(...)
( btw. maybe it is also a bit related to #4442 )