feat(gmail): env-configure --auto-from-addressed-alias via GOG_GMAIL_AUTO_FROM_ADDRESSED_ALIAS - #964
Conversation
…AUTO_FROM_ADDRESSED_ALIAS
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 41272d5b60
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| Attach []string `name:"attach" sep:"none" help:"Attachment file path (repeatable)"` | ||
| From string `name:"from" help:"Send from this email address (must be a verified send-as alias)"` | ||
| AutoFromAddressedAlias bool `name:"auto-from-addressed-alias" help:"When --from is omitted, reply from the verified send-as alias addressed by the original message"` | ||
| AutoFromAddressedAlias bool `name:"auto-from-addressed-alias" help:"When --from is omitted, reply from the verified send-as alias addressed by the original message" env:"GOG_GMAIL_AUTO_FROM_ADDRESSED_ALIAS"` |
There was a problem hiding this comment.
gmail forward
When GOG_GMAIL_AUTO_FROM_ADDRESSED_ALIAS=true is used with gog gmail forward, the setting is never read despite the commit describing forward as supported: GmailForwardCmd has only a From field, and gmail_forward.go:61 resolves the sender directly from c.From before fetching the original message. Consequently forwards still use the default identity rather than the verified alias to which the original was addressed; add the equivalent flag and alias-selection path to GmailForwardCmd, or remove forward from the promised scope.
Useful? React with 👍 / 👎.
clawsweeper
Bot
added
rating: 🧂 unranked krab
|
Codex review: needs real behavior proof before merge. Reviewed August 8, 2026, 11:49 PM ET / August 9, 2026, 03:49 UTC. ClawSweeper reviewWhat this changesThe PR adds Merge readiness⛔ Blocked until stronger real behavior proof is added - 3 items remain Keep open. The change is a narrow reuse of the shipped addressed-alias policy, but the asserted built-binary dry-run proof has no inspectable terminal output or artifact; external PRs need visible after-fix evidence before merge. Priority: P2 Review scores
Verification
How this fits togetherGog’s Gmail commands parse flags and environment defaults into compose options, then choose a verified sender identity before creating a reply or draft. This change supplies a new configuration input while retaining the existing sender-selection logic. flowchart LR
A[CLI flags and environment] --> B[Gmail compose options]
B --> C[Reply or draft command]
C --> D[Verified sender selection]
D --> E[Gmail reply or draft request]
Before merge
Agent review detailsSecurityNone. Review metrics
Merge-risk optionsMaintainer options:
Technical reviewBest possible solution: Retain the opt-in environment default, then add a redacted built-binary terminal transcript showing enabled, unset, and explicit- Do we have a high-confidence way to reproduce the issue? Not applicable: this PR adds an environment-default configuration path rather than reporting broken existing behavior. Current source confirms that the existing sender-selection path is reused. Is this the best way to solve the issue? Yes, subject to proof: binding the environment variable to the existing option is the narrowest implementation and avoids a parallel sender-selection path. AGENTS.md: found and applied where relevant. Codex review notes: model internal, reasoning high; reviewed against 8b33065cbf3d. LabelsLabel changes:
Label justifications:
EvidenceWhat I checked:
Likely related people:
Rank-up movesOptional improvements that raise the rating; they are not merge blockers.
Rating scale
Overall follows the weaker of proof and patch quality. Workflow
HistoryReview history (21 earlier review cycles; latest 8 shown)
|
clawsweeper
Bot
added
merge-risk: 🚨 message-delivery
clawsweeper
Bot
added
rating: 🦪 silver shellfish
|
Current-head signed-binary proof ( Commands exercised the real built CLI with JSON Full local @clawsweeper re-review |
|
🦞🧹 I asked ClawSweeper to review this item again. Re-review progress:
|
|
Landed in The permanent scope is the four existing option owners only: reply, reply-all, draft create, and draft update. The PR body was corrected to remove the unsupported forward claim, and a four-command env-default regression test was added. Verification:
Thanks @ronny-rentner. |
2 participants
Summary
Adds
GOG_GMAIL_AUTO_FROM_ADDRESSED_ALIASas an environment default for the existing--auto-from-addressed-aliasoption, so agents and wrappers can enable the policy without appending a flag to every invocation.The environment default applies to the four command paths that already own the option and sender-selection behavior:
gmail replygmail reply-allgmail drafts creategmail drafts updateIt does not add support to
gmail forward. No behavior changes when the variable is unset, and an explicit--fromretains its existing precedence.Motivation
A bridge that consistently wants replies to use the verified send-as alias addressed by the original message currently has to pass
--auto-from-addressed-aliason every supported command. The environment default follows gogcli's existing env-backed Gmail option conventions without creating a new sender-selection path.Testing
TestGmailAutoFromAddressedAliasEnvDefaults, covering env parsing for all four supported commands.--fromprecedence.make cipasses.Built-binary proof
The signed current-head binary was exercised source-blind with JSON dry runs:
auto_from_addressed_alias: true.false.--from: the plan retained both the enabled option and explicit sender input.Provider-level alias proof is unavailable on the current test host because none of its healthy authenticated Gmail accounts exposes a verified non-primary send-as alias. The provider selection path itself is unchanged from the existing explicit flag.